Neue Blog-Serie: Best Practice


Wie bereits bekannt sein dürfte, schreibe ich hie und da Serien in meinen Blog. Dabei unterscheiden sich die Serien momentan durch zwei Merkmale:

  1. Aus dem Alltag
  2. Themenserien

Die Serie “Aus dem Alltag” beschreibt in der Regel Themen, über welche bei der Installation stolpere Sie setzen sich aus einem Problem, einer Ursache und einer Lösung zusammen.

Themenserien beschäftigen sich mit einzelthemen, welche ich über eine Serie von Posts weiterentwickle (Siehe “SharePoint Governance”)

Nun werde ich eine neue Serie herausbringen, die denke ich für die meisten Techies da draussen interessant sein könnte:

Best Practice

In dieser Serie stelle ich zu verschiedensten Gebieten Best Practice Installations- und Konfigurationstipps dar, welche in der Praxis erprobt sind und wirklich Sinn machen. Dabei gehe ich grundsätzlich von der Best Practice der Microsoft Spezialisten aus und passe diese da und dort unter Berücksichtigung von Security, Stabilität, Fehleranfälligkeit und Betreibbarkeit an oder gebe bisher wenig diskutierte bzw. neue Erkenntnisse weiter.

Für Inputs von eurer Seite bin ich stets dankbarer Abnehmer 🙂

So long, Samuel

TechTalk über SharePoint for Internet Sites


 

Es freut mich, hier den nächsten TechTalk in Wallisellen ankündigen zu können. Ich werde zusammen mit meinem Kollegen Dominique Huber über SharePoint 2010 for Internet Sites sprechen.

Termin: 12 Januar 2010 08:30 – 16:00 Uhr

Agenda:

  • SharePoint 2010 Überblick
  • Versionen und Lizenzierung
  • Architektur
  • Deployment
  • Verwaltung
  • Mehrsprachigkeit
  • Communities
  • Suche
  • Web Analytics
  • Business Connectivity Services
  • Entwicklungstools

Anmeldung:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032473084&Culture=de-CH

So long, Samuel

Die Collaboration Days im Microsoft TechNet Flash 15/10 vom 15.12.2010


 

Es freut mich ausserordentlich, dass es die Collaboration Days so prominent in den TechNet Newsletter geschafft haben.

Vielen Dank Microsoft, vielen Dank René Hanselmann

So long, Samuel Zürcher

Auszug aus dem Editorial:

Collaboration Days in Luzern
Nun sind sie Geschichte: die Collaboration Days in Luzern. Und dies im sprichwörtlichen Sinne – denn mit der ersten Schweizer SharePoint-Konferenz haben die Veranstalter mitten ins Schwarze getroffen. Mit 294 Teilnehmern, sechs Sponsoren und 13 Ausstellern war der Event am 1. Konferenztag restlos ausverkauft. Als Keynote Sprecher konnte Eric Swift, General Manager for SharePoint Products aus Redmond verpflichtet werden. Lesen Sie weiter zu Beginn unter „Aktuell“.

Auszug aus dem Teil “Aktuell”

Collaboration Days 2010 (Fortsetzung aus dem Editorial)

Warum die Collaboration Days entstanden sind? «Wir haben ein klares Bedürfnis für mehr Austausch im SharePoint Land Schweiz gesehen.» So sagt es Stefan Heinz, der die Idee für die Collaboration Days hatte. Zusammen mit Samuel Zürcher, dem Gründer der SharePoint Community Schweiz riefen sie die erste SharePoint-Konferenz der Schweiz ins Leben. Mit im Boot: Microsoft als Hauptsponsor und die Eventfirma HLMC aus München als Organisator.

Das Radisson Blu an der Luzerner Lakefront platzte schier aus allen Nähten, als am 1. Dezember 2010 die Konferenz ihre Tore öffnete. Dem Credo „Creating hands-on Value“ wurden 23 Sprecher in 30 Sessions und 4 Tracks mit qualitativ hochwertigen Themen und praxisnahem Inhalt gerecht. Mit Feedbacks wie «Professionelle Austauschplattform, die auf der ganzen Linie überzeugt hat» ist bereits vor Abschluss der Auswertung klar, dass der Event überzeugen konnte und unbedingt wiederholt werden sollte. Der 29. November 2011 ist als Startschuss für die zweite Folge der Collaboration Days bereits gesetzt.

Aus dem Alltag: 503 Service Unavailable in der Central Administration


Problem:

Nachdem ich bei einem Kunden erfolgreich SQL Server 2008 R2 und SharePoint Server 2010 installiert hatte, erhielt ich beim erstmaligen Öffnen der Central Administration (Zentraladministration) den folgenden Fehler:

Service Unavailable

——————————————————————————-

HTTP Error 503. The service is unavailable.

 

Die Kontrolle im Windows Log ergab folgende drei Einträge:

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5021
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
The identity of application pool SharePoint Central Administration v4 is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request.  If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5057
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
Application pool SharePoint Central Administration v4 has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.

Log Name:      System
Source:        Microsoft-Windows-WAS
Date:          17.12.2010 11:40:31
Event ID:      5059
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      MyServer
Description:
Application pool SharePoint Central Administration v4 has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.

Grund:

Wie aus den Log Einträgen ersichtlich wird, fehlt dem Application Pool Account die folgende Berechtigung “Logon as a batch job”, welche in den Security Policies definiert werden können. In unserem Fall war diese Einstellung von einer überliegenden Policy auf unser System publiziert worden. Diese Berechtigung wird benötigt, damit der Windows Process Activation Service dem entsprechenden Application Pool einen Worker Process zuordnen kann.

Lösung:

  1. Kontrollieren Sie, ob die “Logon as a batch job” Policy von einer höheren Instanz gesteuert wird.
    1. Klicken Sie auf Start –> ausführen
    2. Geben Sie “secpol.msc” ein und drücken Sie Enter
    3. Navigieren Sie zu Local Policies –> User Rights Assignment –> Log on as a batch job
      image
  2. Ist die “Logon as a batch job” Policy nicht übersteuert, kontrollieren Sie ob IIS_IUSRS berechtigt sind. Wenn nicht, vergeben Sie diese.
  3. Ist die Policy übersteuert (sie können lokal keine Änderungen vornehmen), so bearbeiten Sie die entsprechend übergeordnete Policy:
    1. Erstellen Sie eine Active Directory Gruppe, welcher Sie alle Application Pool User von SharePoint zuordnen (inkl. dem Service User für die Service Applications (SharePoint 2010) oder dem Shared Services Provider (SharePoint 2007) und dem Farm User für die Central Administration)
    2. Fügen Sie die Active Directory Gruppe der die Policy “Logon as a batch job” hinzu

So long, Samuel Zürcher

SharePoint Governance Teil V: Rechte


Kommen wir nun zum Bereich Rechte. Natürlich ist es auf jeder Plattform essentiell, sich über Rechte oder Berechtigungen zu unterhalten. Hier kommen wir an einen Punkt, der sehr kontrovers und z.T. auch heiss diskutiert wird. Wir wollen versuchen, den Weg der Best Practices zu verfolgen. Um eine saubere Rechtestruktur zu vermitteln, muss ich etwas ausholen und teile diesen Blogpost in verschiedene Teile ein.

Einführung

In der Rechtevergabe bei SharePoint möchte ich es sehr einfach halten. Wir unterscheiden SharePoint Gruppen, Active Directory Gruppen, User und Berechtigungsstufen.

Berechtigungselement Beschreibung
SharePoint Gruppe SharePoint Gruppen werden in SharePoint selbst angelegt. Sie dienen dazu, Inhalte von SharePoint mit Berechtigungen zu versehen. Sie enthalten User oder Active Directory Gruppen, nie aber weitere SharePoint Gruppen. SharePoint Gruppen werden von der IT oder von Super Usern gemanaged und auf Site Collections, Sites, Bibliotheken, Listen oder einzelne Items vergeben.
Active Direcotry Gruppe Diese Gruppen werden von der IT gemanaged. Sie enthalten User und sind z.T. auch im Outlook als Verteilergruppen sichtbar. Sie können in SharePoint Gruppen vergeben oder direkt wie solche verwendet werden.
User User werden von der IT im Active Directory angelegt. Sie regeln den Zugang zu Systemen und setzten sich aus einem Login und einem Passwort zusammen. Zusätzlich können weitere Informationen zum User hinterlegt werden.
Berechtigungsset Sie regeln die eigentliche Berechtigung auf einer Seite bzw. einem Item(Dokumente etc.) Stichwort dazu: CRUD (Create, Read, Update, Delete). Berechtigungssets werden an AD Gruppen, SP Gruppen oder User angehängt.

Es gibt folgende Arten, Berechtigungen zu steuern:

  1. Vergeben von Rechten direkt an User (DON’T DO THIS)
  2. Vergeben von Rechten direkt an AD Gruppen (DON’T DO THIS)
  3. Erstellen von SharePoint Gruppen und einfügen von AD Gruppen
  4. Erstellen von SharePoint Gruppen und einfügen von Usern
  5. Erstellen von SharePoint Gruppen und eine Kombination von 3 + 4 (Für die meisten Szenarien empfohlene Variante)

Es gibt Szenarien, wo es durchaus Sinn macht, alles in AD Gruppen zu steuern und diese in SharePoint Gruppen zu verteilen (Nr. 3) doch meistens macht es sinn, diesen Aufwand von der IT wegzunehmen und an Power User zu übergeben. Warum? Die IT weiss meist so wie so nicht, ob diese Rechte Sinn machen oder nicht. Sie befolgen einen Auftrag, der meist per Formular zu ihnen gekommen ist. Warum nicht die Abteilungen ihre Rechte mit einem definierten Prozess selbstständig regeln lassen? AD Gruppen werden so wie so gepflegt, also alles was so wie so gepflegt wird mit AD Gruppen lösen. Was aus dem Schema fällt löst man dann besser mit einzelnen Usern, welche man den SharePoint Gruppen zusätzlich zu den bereits bestehenden AD Gruppen hinzufügt.

Also nochmal zur Repetition: User kommen automatisch in AD Gruppen. Diese wiederum verteilt man in SharePoint Gruppen, wo das nicht reicht, ergänzt man die SharePoint Gruppen mit einzelnen Usern.

SharePoint Gruppen

Versuchen Sie die meisten Szenarien mit den SharePont Standardgruppen zu lösen. Wenn eine Webseite erstellt wird, so stehen folgende SharePoint Gruppen zur Verfügung.

  1. Besitzer von…
  2. Besucher von…
  3. Mitglieder von…

image

Sobald Publishing (Veröffentlichungs-Infrastruktur) auf Site Collection Ebene aktiviert wird, kommen folgende SharePoint Gruppen dazu:

  1. Anzeigende Benutzer
  2. Designer
  3. Formatressourcenleser
  4. Genehmigende Personen
  5. Hierarchie-Manager
  6. Personen mit eingeschränkten Leserechten

image

Diese Gruppen werden nun auf der Ebene Site Collection, Site, Bibliothek, Liste oder Item vergeben. Natürlich kann man auch beim sogenannten Brechen von Berechtigungen einzelne User oder AD Gruppen vergeben, doch dies ist absolut nicht empfehlenswert, da sonst der Überblick verloren geht.

Rightsmanagement

Eine Site Collection vererbt an seine Inhalte (Unterwebseiten, Bibliotheken, Listen, Items), Eine Webseite vererbt an seine Inhalte (Unterwebseiten, Bibliotheken, Listen, Items), eine Bibliothek bzw. Liste vererbt an seine Inhalte (ggf. Ordner, Items). An jeder Stelle kann die Vererbung gebrochen und eine SharePoint Gruppe, eine AD Gruppe oder ein User eingesetzt werden. Wir auf der Ebene Webseite gebrochen, so vererbt diese Webseite die neu eingesetzten Berechtigungen wiederum auf die Unterwebseiten, Bibliotheken, Listen und Items. Wird auf der Ebene Bibliothek gebrochen, so erben danach ggf. Ordner und Items. Wird auf der Ebene Item gebrochen so betrifft es nur noch dieses Item.

Berechtigungsstufen

Grundsätzlich gibt es sechs Berechtigungsstufen. Natürlich kann man sich ganz individuelle Berechtigungsstufen konfigurieren, doch SharePoint liefert in der Grundstruktur sechs Stufen:

  1. Teilnehmen (Neu: Mitwirken)
  2. Lesen
  3. Vollzugriff
  4. Design
  5. Beschränkter Zugriff
  6. Nur lesen

Designen wird wird oft nur aufgrund von Szenarien gebraucht, bei welchen mit Genehmigungen (Einstellung in einer Bibliothek oder Liste) gearbeitet wird. Es empfiehlt sich jedoch, für Genehmigungen entweder die Publishing Gruppe “Genehmigen” zu benutzen, diese wird allerdings nur sichtbar, wenn Publishing auf der Site Collection aktiviert ist. Wenn Publishing nicht eingesetzt wird oder lediglich die SharePoint Foundation eingesetzt wird würde ich das Teilnehmen Berechtigungsset kopieren, neu benennen und zusätzlich Genehmigungsrechte zu vergeben.

image

Wird das Publishing aktiviert (Veröffentlichungs-Infrastruktur), stehen zusätzlich folgende Berechtigungsstufen zur Verfügung:

  1. Genehmigen
  2. Hierarchie verwalten
  3. Eingeschränkter Lesezugriff

image

Ich rate Ihnen an, sich an diese Standard Gruppen zu halten, denn mit ihnen lassen sich 90% aller Szenarien abbilden. Sie begeben sich auf dünnes Eis, wenn Sie anfangen, eigene Berechtigungsstufen zu erstellen.

Ausnahmen:

  • Sie benötigen ein Berechtigungsset, welches das Löschen von Content ausschliesst, nicht aber das Erstellen oder das Ändern von Content.
  • Sie arbeiten mit SharePoint Fundation und haben an ein- oder mehreren Stellen die Inhaltsgenehmigung aktiviert

Jede SharePoint Gruppe (und wenn man einzelne User oder AD Gruppen direkt berechtigen würde diese auch) erhält nun eine solche Berechtigungsstufe. Die Berechtigungsstufe definiert, welche Rechte die Gruppe am eingesetzten Ort hat. Auch hier gibt es natürlich auch Spielvarianten, wie Gruppe A hat auf der Bibliothek B grundsätzlich “Mitwirken” als Berechtigungsstufe, doch auf dem Ordner X in der Bibliothek B hat die selbe Gruppe A nur “Lesen”. Auch hier ist absolute Vorsicht geboten, man kann also ggf. nicht davon ausgehen, dass eine Gruppe einfach überall diese Rechte hat, wie es den Anschein haben mag.

Roundup

Wie wir nun sehen, ist das Ganze schon an und für sich komplex. Wenn Sie nun anfangen, die Berechtigungen wild zu vergeben (Person X und Y haben Rechte auf Ordner A und B, Person Y und Z haben Rechte auf Ordner C und D etc.), dann werden Sie sich schon bald im puren Chaos wiederfinden. Wie stellt man also sicher, dass die Berechtigungen einigermassen im Griff zu halten sind?

Hier kommen wir nun zurück auf die Rollen. Es ist meines Erachtens zwingend, dass man die definierten Rollen auch gleich dazu verwendet, die Berechtigungen festzulegen. Welche Rolle hat welche Gruppenzugehörigkeit? Damit ist auch gleich klar, was die Rolle für Berechtigungen hat.

Szenario:
Sie haben ein Projekt, in welchem verschiedene Personen involviert sind. Sie möchten gerne die Berechtigungen dazu festlegen, wie gehen sie am besten vor.

Methode A:
Sie vergeben die Berechtigungen der Personen direkt auf die Ordner und Inhalte anhand Ihren Bedürfnissen.

Vorteile Nachteile
  • Direkte und individuelle Vergabe von Rechten möglich
  • Keine Übersicht über die vergebenen Rechte
  • Schwieriges Szenario bei neuen Projektmitgliedern (Wo muss die Person überall berechtigt sein?
  • Viel Zeitaufwand beim managen der Zugriffe
  • Um einigermassen den Überblick zu erhalten muss ein Excel mit den vergebenen Rechten geführt werden.

 

Methode B:
Sie vergeben die Berechtigungen der Personen mittels verschiedenen SharePoint Gruppen

Vorteile Nachteile
  • Gute Übersicht durch vorhandene Gruppen
  • Individuelle Vergabe von Rechten möglich
  • Schwieriges Szenario bei neuen Projektmitgliedern (In welche SharePoint Gruppen muss die Person verteilt werden?)
  • Nach wie vor viel Zeitaufwand beim managen der Zugriffe
  • Es muss ein Excel geführt werden, welche Gruppe wo Zugriff hat, und wer in welcher Gruppe ist.

 

Methode C:
Sie definieren klare Rollen (Projektleiter, Projektassistenz, Projektmitarbeiter, Berater, Besucher), erstellen pro Rolle eine SharePoint Gruppe mit entsprechender Berechtigungsstufe und verteilen die User nach ihren Rollen in eine der Gruppen. Die SharePoint Gruppen werden dann auf den Inhalt verteilt. (Projektleitungsordner etc.)

Vorteile Nachteile
  • Gute Übersicht durch vorhandene Gruppen
  • Schnelle Vergabe von Rechten möglich
  • Klare Verwaltung der Zugriffe
  • Bei Wechsel im Projekt müssen Sie die neue Person nur gemäss ihrer Rolle in eine der Gruppen berechtigen
  • Es braucht lediglich ein Grundkonzept welche Rolle was darf, dies ist danach generisch auf alle weiteren Projekte anwendbar
  • Gewisse Einschränkungen durch die Bindung an ein Rollenmodell und daraus entstehender Mehraufwand bei der Planung

 

Wie Sie sehen, ist Methode C die beste Wahl. Wenn ich betrachte, wie viel Aufwand betrieben werden muss um die Berechtigungen einigermassen im Griff zu halten, ist Methode C die zumindest erfolgversprechendste der drei Methoden. Ansonsten müssen Leintuchmässige Excel Listen geführt werden, um zu wissen, wer wo berechtigt ist.

Fazit

Ich möchte folgende Kernaussagen festhalten:

  • Verwenden Sie die Rollen, um die Berechtigungen zu bestimmen.
  • Nehmen Sie den initialen Aufwand in Kauf, dass für jedes Szenario Rollen gebildet werden müssen, sie werden es dafür später leichter haben.
  • Lassen Sie sich nicht von der Angst der unflexibilität in eine wilde Rechtevergabe treiben
  • Anwender möchten immer gerne alles in einem kleinen Garten geschützt haben (Ich und X haben Zugriff auf Ordner A etc.), doch dies ist nicht verwaltbar.
  • Verwenden Sie möglichst viel die Standardgruppen von SharePoint
  • Verwenden Sie möglichst ausschliesslich die Standard Berechtigungsstufen von SharePoint

Das Berechtigungsmanagement ist eines der heikelsten und auch der kontroversesten Themen im SharePoint. Lassen Sie sich nicht verwirren, es braucht eine Zeit bis man ein klares Konzept davon erfassen kann.

Lo long, Samuel

Subscribe to my Blog


Neu ist es möglich, sich für meinen Blog zu subscriben.

Variante 1: Sie haben einen WordPress Account und loggen sich ein, dort können Sie sich auf meinen Blog subscriben (Rechte Seite –> Subscribe)

Variante 2: Sie geben Ihre E-Mail Adresse in das Feld ein und klicken auf Abonnieren (Rechte Seite –> Subscribe)

Ich freue mich auf viele Besucher 🙂

So long, Samuel