SQL Script für die Erstellung von Best Practice SharePoint Datenbanken

Na dass wird aber auch Zeit. Endlich poste ich auch hier zur Vollständigkeit den Post, welchen ich im SharePointAdvent gepostet habe. Er ist die Fortsetzung vom Post Best Practice SQL Setup.

Wie in meinem letzten Post erläutert, macht es durchaus Sinn, sich im Bereich SharePoint auch über das Backend Gedanken zu machen. Ein Teil davon ist die Erstellung der Datenbanken. Eigentlich sollte es den Button "Add new Content Database" in SharePoint gar nicht geben.

Warum? Hier sind die Gründe:

SharePoint erstellt eine neue Datenbank ab der Model und diese ist von Natur aus so konfiguriert:

• 2MB gross (oder besser gesagt klein)
• Ein einzelnes File in der Primary Filegroup
• Growth ist auf 1 MB Unlimited Growth
• Logfile ist 1MB gross
• Growth ist 10%

Nach dem Erstellen einer leeren SharePoint Datenbank ist diese 2o MB gross, das heisst, sie ist bereits 18x gewachsen. Durch das Wachstum einer DB wird sie fragmentiert und wie man weiss, ist alles was fragmentiert ist langsamer, da die Datenstücke nicht aneinander hängen, sondern verteilt sind. Diese Verteilung muss vom DB Management System aufgefangen werden. Dieser Reibungsverlust schlägt sich in der Performance nieder.

Wenn ich nun die DB Stats abfrage, bekomme ich den Fragmentierungslevel der neuen Datenbank mitgeteilt, ACHTUNG: Es handelt sich notabene um eine leere SharePoint Datenbank, die noch überhaupt keinen Content enthält. SELECT * FROM sys.dm_db_index_physical_stats (DB_ID(‚DB Name‘), Null, Null, Null, Null);

Ich erhalte hier 230 Rows, jede Row enthält den Hinweis auf einen Index. Meine Datenbank ist also schon sehr stark fragmentiert, obwohl sie leer ist. Da kann man sich vorstellen, dass dies an der Performance nagt.

Ein weiterer Punkt ist, dass allea auf einem Datenfile abgeht. Heute haben Prozessoren mehrere Kerne, und jeder hackt auf dem armen File rum. Viel besser ist es, wenn jeder Kern sich auf ein anderes File konzentrieren kann. Wenn eine DB in mehrere Files unterteilt ist, so wird abwechselnd auf die Files eingedroschen, was sich wiederum positiv auf die Performance auswirkt. Die Fausregel sagt, dass pro Prozessorkern 0.25 bis 0.5 Files angelegt werden sollten, mindestens aber 4. Bei mehr als 8 Files ist dann kein grosser Unterschied mehr spürbar. Beachten Sie folgendes:

• Berechnen Sie vorab, wie viel Content später mal in die DB rein soll
• Erstellen Sie die initiale DB Grösse entsprechend ein (wir sprechen von GB nicht von BYTES)
• Stellen Sie das Wachstum auf eine vernünftige Grösse ein
• Stellen Sie das LOG auch auf 1GB oder teilbar durch 8GB

Hier kommt der Script vorher noch im SQL Mgmt Studio unter "Query" den "SQL CMD Mode" aktivieren, alles was rot ist muss von euch noch customized werden (auch der User ganz am Ende, da kommt der Farm Admin rein:

/*—————————————————————————————
  Disclaimer – Thoroughly test this script, execute at your own risk.
  —————————————————————————————
 
  set variables (Filesizes in MB)*/
:setvar DBName MyAdventDB
:setvar LoginitialMB 1024
:setvar LoggrowMB 1024
:setvar DatainitialMBperFile 341
:setvar DatagrowMBperFile 341
:setvar DataPath “C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA”
:setvar LogPath “C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA”
 
CREATE DATABASE [$(DBName)] ON  PRIMARY
/*no grow on Primary-File (its only for sys tables and Service Broker Queues)*/
( NAME = N’$(DBName)Data01′, FILENAME = N’$(DataPath)\$(DBName)Data01.mdf‘ , SIZE = 128MB , FILEGROWTH = 0),
/* 0.25-1 file per cpu core (each with same initial and grow size)*/
( NAME = N’$(DBName)_Data02′, FILENAME = N’$(DataPath)\$(DBName)_Data02.ndf‘ , SIZE = $(DatainitialMBperFile)MB , FILEGROWTH = $(DatagrowMBperFile)MB ),
( NAME = N’$(DBName)_Data03′, FILENAME = N’$(DataPath)\$(DBName)_Data03.ndf‘ , SIZE = $(DatainitialMBperFile)MB , FILEGROWTH = $(DatagrowMBperFile)MB ),
( NAME = N’$(DBName)_Data04′, FILENAME = N’$(DataPath)\$(DBName)_Data04.ndf‘ , SIZE = $(DatainitialMBperFile)MB , FILEGROWTH = $(DatagrowMBperFile)MB ),
( NAME = N’$(DBName)_Data05′, FILENAME = N’$(DataPath)\$(DBName)_Data05.ndf‘ , SIZE = $(DatainitialMBperFile)MB , FILEGROWTH = $(DatagrowMBperFile)MB )
LOG ON
/* place tlog on another diskarray, use best practice size for optimal vlf handling (1GB/8GB)*/
( NAME = N’$(DBName)_log‘, FILENAME = N’$(LogPath)\$(DBName)_log.ldf‘ , SIZE = $(LoginitialMB)MB , FILEGROWTH = $(LoggrowMB)MB )
/* collation for database */
COLLATE Latin1_General_CI_AS_KS_WS
GO
/* 90=2005/100=2008*/
ALTER DATABASE [$(DBName)] SET COMPATIBILITY_LEVEL = 100
GO
ALTER DATABASE [$(DBName)] SET ANSI_NULL_DEFAULT OFF
GO
ALTER DATABASE [$(DBName)] SET ANSI_NULLS OFF
GO
/* set ANSI_PADDING True, refer to BOL for more information, not default setting*/
ALTER DATABASE [$(DBName)] SET ANSI_PADDING ON
GO
ALTER DATABASE [$(DBName)] SET ANSI_WARNINGS OFF
GO
ALTER DATABASE [$(DBName)] SET ARITHABORT OFF
GO
ALTER DATABASE [$(DBName)] SET AUTO_CLOSE OFF
GO
ALTER DATABASE [$(DBName)] SET AUTO_CREATE_STATISTICS ON
GO
/* never use AUTO_SHRINK on a production DB*/
ALTER DATABASE [$(DBName)] SET AUTO_SHRINK OFF
GO
ALTER DATABASE [$(DBName)] SET AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE [$(DBName)] SET CURSOR_CLOSE_ON_COMMIT OFF
GO
ALTER DATABASE [$(DBName)] SET CURSOR_DEFAULT  GLOBAL
GO
ALTER DATABASE [$(DBName)] SET CONCAT_NULL_YIELDS_NULL OFF
GO
ALTER DATABASE [$(DBName)] SET NUMERIC_ROUNDABORT OFF
GO
ALTER DATABASE [$(DBName)] SET QUOTED_IDENTIFIER OFF
GO
ALTER DATABASE [$(DBName)] SET RECURSIVE_TRIGGERS OFF
GO
ALTER DATABASE [$(DBName)] SET  DISABLE_BROKER
GO
ALTER DATABASE [$(DBName)] SET AUTO_UPDATE_STATISTICS_ASYNC OFF
GO
ALTER DATABASE [$(DBName)] SET DATE_CORRELATION_OPTIMIZATION OFF
GO
ALTER DATABASE [$(DBName)] SET PARAMETERIZATION SIMPLE
GO
ALTER DATABASE [$(DBName)] SET  READ_WRITE
GO
/* use same recovery model for each db in an instance (exceptions in olap environments)*/
ALTER DATABASE [$(DBName)] SET RECOVERY FULL
GO
ALTER DATABASE [$(DBName)] SET  MULTI_USER
GO
/* change all dbs to checksum since 2005*/
ALTER DATABASE [$(DBName)] SET PAGE_VERIFY CHECKSUM
GO
 
/* change db owner*/
USE [$(DBName)]
GO
EXEC dbo.sp_changedbowner @loginame = N’domain\user‘, @map = false
GO

 

Am Ende noch mit Powershell an SharePoint anhängen und gut ist.

New-SPContentDatabase -Name <ContentDbName> -WebApplication <WebApplicationName>

So long, Samuel

Live Chat mit General Manager Sharepoint

Am Do. den 2. Juni 2011 11:00-12:00 Uhr gibt es auf Facebook einen Live Chat mit dem general Manager for SharePoint Products Eric Swift. Er eröffnete die Collaboration Days 2010 (Video: http://www.sharepointcommunity.ch/spcast/CollabDays2010/KEYNOTE.aspx)

Hier gehts zum Event: http://www.facebook.com/event.php?eid=220604931302689

So long, Samuel

Registrieren Sie sich für die SharePoint Konferenz 2011 in USA

	Register now to attend Microsoft SharePoint Conference, the premier worldwide conference dedicated to SharePoint and related technologies! SharePoint Conference 2011 will be the only conference to hear experts from Microsoft and around the world share their experience and knowledge about a variety of topics such as cloud services, best practices & real world project insights.  The session content will cover products including SharePoint and SharePoint Online as part of the soon to be released Office 365. Whether you are an IT Professional, IT Manager, Architect, Developer or Project Manager, SharePoint Conference 2011 will give you the tools, knowledge and skills you need to get the most value from your SharePoint investment and projects. Whether you are just getting started with SharePoint or have deep technical experience, SharePoint Conference 2011 will have the content to help you plan, develop, deploy, and govern your SharePoint solution. In addition to exclusive session content you will have access to Hands on Labs, as well as opportunities to network with technical and industry experts including Microsoft engineers, Microsoft Most Valuable Professionals (MVPs), Microsoft Certified Masters (MCMs), SharePoint customers and many of our top Certified Partners. The conference registration fee for SharePoint Conference 2011 is $1,199 and seats are limited!  The 2009 conference sold out fast so don’t miss your chance – register now!

Noch 3 Tage: Sprechen Sie an der SharePoint Europe Konferenz

Wie bereits bekannt sein dürfte, findet vom 17. – 20. Oktober 2011 die europäische SharePoint Konferenz statt. http://www.sharepointeurope.com/Pages/Home.aspx

Sprecher haben noch drei Tage Zeit, sich für einen Vortrag zu bewerben. http://www.sharepointeurope.com/Pages/CallForSpeakers.aspx

Wenn Sie wissen wollen, was am 3.10.2011 in Amerika an der SharePoint Konferenz besprochen wird, dann besuchen Sie die SharePoint Europe Konferenz.

http://videos.sproutvideo.com/embed/4c98d2ba1f1ae3c5c4/e8789f76952c090c?type=hd&autoplay=true

 

Wir sehen uns da

So long, Samuel

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

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
   
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…

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

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.

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.

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

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

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