SharePoint - Rollen und Berechtigungen (3)

In der Artikelreihe "SharePoint - Rollen und Berechtigungen" wird auf die Konzeption von Berechtigungensvergabe und planen der benötigten Rollen für den SharePoint Betrieb eingegangen. Die Erfahrung zeigt, dass diese Konzeption an die Technologie "SharePoint" angepasst werden muss und zur Einführung eines SharePoint Systems nicht vernachlässigt werden darf. Bereits zwei Artikel sind zu diesem Thema erschienen, zum einem ein Artikel über Rollen ( SharePoint - Rollen und Berechtigungen (1) ) und ein Artikel über Authentifizierung ( SharePoint - Rollen und Berechtigungen (2) ). Insgesamt umfasst das Thema drei Artikel:

1. Rollen,
2. Authentifizierung,
3. Autorisierung.

Dieser Artikel über Autorisierung ist somit der letzte Artikel der thematischen Behandlung von Rollen und Berechtigungen in SharePoint und der letzte Artikel vor einem Fazit.

3. Autorisierung

 Die vorangegangen Artikel über Rollen und Authentifizierung bilden die Grundlage für das Thema der Autorisierung in SharePoint.
Die Autorisierung bezeichnet die Zuweisung und die Überprüfung von Zugriffsrechten in SharePoint. Grundlage für die Autorisierung ist eine erfolgreiche Authentifizierung. Nur wenn der Benutzer dem System bekannt ist kann es die zugewiesenen Zugriffsrechte des Benutzers überprüfen. Zugriffsrechte können in SharePoint rechte granular über die einzelnen Hierarchiestufen der Elemente vergeben werden. Die folgende Abbildung stellt eine solche Hierarchie - oder auch Seitenstruktur - mit den entsprechenden Elementen dar.



Zugriffsrechte können auf jeder Ebene dieser Seitenstruktur vergeben. Wichtig dabei zu wissen ist, dass sich die Zugriffsrechte in dieser Seitenstruktur nach unter weiter vererben. Diese Vererbung lässt sich aber an beliebigen stellen, in der Abbildung sind die Pfeile diese Stellen, unterbrechen. Granulare Vergabe von Zugriffsrechten ist also möglich, zum Beispiel das Unterbrechen der Vererbung auf einem SharePoint Element vom Typ "Aufgabe", so dass nur ein bestimmer Personenkreis diese Aufgabe sehen kann. Auch sind bestimmte Zugriffsrechte in SharePoint bekannt, die einem Benutzer zu verschiedenen Aktionen befähigen. Hat ein Benutzer das Zugriffsrecht Lesen, kann er Dokumente zwar öffnen, aber nicht zurück speichern. Hierfür würde er das Zugriffsrecht Mitwirken benötigen. Diese verschiedenen Arten von Zugriffsrechte nennt man in SharePoint Berechtigungsstufen oder Permission Level.
Die Zuweisung und somit auch die Überprüfung von Zugriffsrechten kann für einzelne Benutzer oder für im Vorfeld definierte Gruppen von Benutzern erfolgen. Einer der Vorteile beim Verwenden von Gruppen liegt auf der Hand; ändert sich die Zugehörigkeit zu einer solchen Gruppe, müssen die Berechtigungen nicht über die gesamte Seitenstruktur neu vergeben werden! Die Grundlage der Benutzer und Gruppen sind die im zweiten Artikel über Authentifizierung benannten und erläuterten Benutzerquellen. In der Regel kann man Benutzergruppen schon in der Benutzerquelle verwalten, zusätzlich ist dies aber auch im SharePoint möglich.
Die Vielzahl an Berechtigungsstufen und die Möglichkeiten bei der Zuweisung von Zugriffsrechten durch Benutzerquellen und Gruppen lassen erahnen, dass die Autorisierung in SharePoint eine hohe Komplexität annehmen kann. Eine weit verbreitete Best Practice zum Umgang mit dieser hohen Komplexität rät zum konsequenten Verwenden von Benutzergruppen.

Die Abbildung setzt als Benutzerquelle für SharePoint ein Active Directory System - kurz AD - voraus. Alle Benutzerkonten werden in diesem AD wieder in Benutzergruppen zusammengefasst. Diese Benutzergruppen sind im Idealfall entsprechend der Unternehmensorganisation aufgebaut und losgelöst von Anwendungen oder der Seitenstruktur des SharePoints. Daher kann das AD und seine Gruppen durch einen eigenen Administrator ohne Zusammenarbeit mit einem SharePoint Administrator gepflegt werden. In SharePoint wiederrum werden SharePoint Gruppen entsprechend der Funktionalität der Seitenstruktur eingerichtet. Die im ersten Artikel über erläuterte Rolle des Website Administrator legt diese Gruppen an, weißt Ihnen eine Berechtigungsstufe zu und befüllt sie mit den Benutzergruppen aus dem AD. Am Beispiel einer Abteilungsseite würde dies bedeuten, dass der Website Administrator eine Gruppe Seitenbesitzer, Abteilungsmitglieder und Leser einrichtet und diese mit den AD Benutzergruppen Abteilungsleiter, Abteilungsmitglieder und allen anderen Abteilungsgruppen befüllt. Die Kompetenz der Pflege der Unternehmensorganisation liegt bei einem AD Administrator, die Kompetenz der Zuweisung von Berechtigungsstufen beim Website Administrator. In unserem Beispiel würde das bedeuten, dass ein Website Administrator nicht mehr aktiv eingreifen muss, sollte sich die Abteilungleitung ändern - durch die Pflege der Benutzergruppen hätte der neue Abteilungsleiter die gleichen Zugriffsrechte wie der alte Abteilungsleiter! Diese Best Practice hat also folgende Vorteile:

• Die Kompetenzen von der Abbildung von Unternehmensorganisation und Abbildung von Zugriffsrechten im SharePoint werden entkoppelt - und so sowohl der Aufwand verteilt als auch die Fehler bei der Abbildung von Zugriffsrechten gering gehalten.
• Der Pflegeaufwand wird durch die Verwendung der Gruppen minimiert, da nicht für jedes einzelne Benutzerkonto agiert werden muss.

Ohne diese Best Practice und bei der Zuweisung von Zugriffsrechten direkt an ein Benutzerkonto ist die administrative Kontrolle der Zugriffsrechte und die Wartbarkeit des Systems stark gefährdet. Denn Anforderungen wie "Der neue Kollege benötigt exakt die gleichen Rechte!" werden zu einem Problem, welchem nur überdimensionalem Aufwand begegnet werden kann!

Die Fragen, welche sich für eine Konzeption der Autorisierung stellen, sind recht übersichtlich:

• Welche Berechtigungsstufen ( Zugriffsrechte ) müssen zur Verfügung gestellt werden?
• Stehen Benutzergruppen in der Benutzerquelle ausreichend zur Verfügung?
• Wer muss in der Zuweisung von Zugriffsrechten geschult werden?

Gerade der letzten Frage kommt besondere Bedeutung zu. Nicht nur, da die Best Practice für den Key User aus der Fachabteilung durchaus unverständlich sein kann, sondern vor allem da Sie eigentlich im Gegensatz zu den im ersten Artikel beschriebenen Verhältnis der Rollen steht. Je mehr Schlüsselbenutzer aus der Fachabteilung man als Website Administrator ausbildet, um so größer wird der Erfolg beim Einsatz von SharePoint und um so kleiner wird der Aufwand für die interne IT Abteilung. Jedoch: Je mehr Benutzer aus der Fachabteilung Zugriffsberechtigungen zuweisen, um so geringer wird der Erfolg der Best Practice sein!

Wieso Rollen, Authentifizierung und Autorisierung im Zusammenspiel keine wasserdichte Konzeption für SharePoint erlauben und was man dagegen unternehmen kann werden wir im nächsten Artikel, dem Fazit, genauer betrachten.

Good Luck,

Andreas

SharePoint, PowerShell und Taxonomy

Eines der spannensten Features in SharePoint 2010 ist sicherlich der Managed Metadata Service und Taxonomien. Die Produktversion 2010 ist frisch mit diesem Feature bereichert worden. Daher ist gerade für Anwender, die schon ältere Produktversionen wie den Office SharePoint Server 2007 oder die Windows SharePoint Services 3.0 eingesetzt haben Umdenken angesagt! Hat man sich früher mit Auswahl- und Nachschlagefelder auf Schlagwortlisten beholfen, kann man heute Managed Metadata einsetzen! Dies erfordert allerdings auch neue Anforderungen an die Administration und schafft neue Herausforderungen bei der Migration - denn wer will schon die alten Notlösungen weiter verwenden, wenn er jetzt ein neues Feature dafür hat?! Die Erfahrung zeigt, dass man sich für solche Migrationen von alten Schlagwortspalten in Taxonomien oftmals am besten mit individuellen PowerShell Skripts behilft. Daher möchte ich im folgenden Skript- Beispiele für die häufigsten Anwendungsfälle bereit stellen.

1. ####   
2. # www.letssharepoint.com   
3. ####   
4.   
5. # Get Taxonomy Session and Term Store   
6. $site = Get-SPSite http://yoursiteurl   
7. $taxonomySession = Get-SPTaxonomySession -site $site  
8. $termStore = $taxonomySession.TermStores["Your Managed Metadata Service Application"]   
9.   
10. # Create Groups   
11. $termStoreGroup = $termStore.CreateGroup("Your Groupname")   
12. $termStoreGroup.Description = "Your Description"    
13. $termStoreGroup.AddGroupManager("domain\user")   
14. $termStoreGroup.AddContributor("domain\user")   
15.   
16. # Create Termset   
17. $termSet = $termStoreGroup.CreateTermSet("Your Termset name")   
18.   
19. # Create Term   
20. $term = $termSet.CreateTerm("Your Term Name", LanguageID)   
21.   
22. $termStore.CommitAll()  

Das Beispiel Skript oben zeigt, wie man sich gegen einen Term Store verbindet und neue Gruppne, Term Sets und Terms anleget. Zu beachten ist, das bei der Methode CreateTerm die LanguageID ausgetauscht werden muss!

1. ####   
2. # www.letssharepoint.com   
3. ####   
4.   
5. # Load Microsoft.SharePoint.Taxonomy to work with TaxonomyFieldValueCollection   
6. [Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Taxonomy")   
7.        
8. # Get Taxonomy Session and Term Store   
9. $site = Get-SPSite http://yoursiteurl   
10. $taxonomySession = Get-SPTaxonomySession -site $site  
11. $termStore = $taxonomySession.TermStores["Your Managed Metadata Service Application"]   
12.   
13. # Get Web, List item and Taxonomy Field   
14. $web = Get-SPWeb http://yourweburl   
15. $list = $web.Lists["YourList"]   
16. $item = $list.GetItemById(1)   
17. $taxField = $item.Fields["YourTaxField"]   
18.   
19. # Create Taxonomy Field Collection for a Multi Managed Metadata Field   
20. $taxCollection = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValueCollection $taxField  
21.   
22. ## Get Terms and Add them to the TaxonomyFieldValueCollection   
23. # Get Term Group   
24. $termStoreGroup = $termStore.Groups["My Group"]   
25. # Get Term Set   
26. $termSet = $termStoreGroup.TermSets["My Termset"]   
27. # Get Terms    
28. $term1 = $termSet.Terms["Term1"]   
29. $term2 = $termSet.Terms["Term2"]   
30. $term3 = $termSet.Terms["Term3"]   
31. # Get TaxonomyFieldValues   
32. $taxValue1 = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue($taxField)   
33. $taxValue1.TermGuid = $term1.Id   
34. $taxValue1.Label = $term1.Name   
35. $taxValue1.WssId = -1   
36. $taxValue1 = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue($taxField)   
37. $taxValue2.TermGuid = $term2.Id   
38. $taxValue2.Label = $term2.Name   
39. $taxValue2.WssId = 0   
40. $taxValue3 = new-object Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue($taxField)   
41. $taxValue3.TermGuid = $term3.Id   
42. $taxValue3.Label = $term3.Name   
43. $taxValue3.WssId = 1   
44. # Add Values to Tyxonomy Field Value Collection   
45. $taxCollection.Add($taxValue1)   
46. $taxCollection.Add($taxValue2)   
47. $taxCollection.Add($taxValue3)   
48.   
49. # Update Managed Metadata Colum on Item   
50. $taxField = SetFieldValue($item, $taxCollection)   
51. $item.Update()  

Dieses Skript Beispiel zeigt, wie man eine Spalte vom Typ "Verwaltete Metadaten", welche mehrere Werte zulässt, befüllt. Im hier gezeigten Fall werden drei Werte in der Spalte gesetzt. Die WssId des TaxonomyFieldValues wird einfach hochgezählt, sofern das Feld noch nicht mit anderen Werten befüllt ist.

Good Luck,

Andreas

SharePoint - Rollen und Berechtigungen (2)

In der Artikelreihe "SharePoint - Rollen und Berechtigungen" wird auf die Konzeption von Berechtigungensvergabe und planen der benötigten Rollen für den SharePoint Betrieb eingegangen. Die Erfahrung zeigt, dass diese Konzeption an die Technologie "SharePoint" angepasst werden muss und zur Einführung eines SharePoint Systems nicht vernachlässigt werden darf. Im ersten Artikel SharePoint - Rollen und Berechtigungen (1) wurden bereits die folgenden drei Themengebiete identifiziert, die bei der Konzeption berücksichtigt werden müssen:

1. Rollen,
2. Authentifizierung,
3. Autorisierung.

Das erste Themengebiet "Rollen" wurde bereits behandelt, daher wird in diesem zweiten Artikel auf die Authentifizierung eingegangen.

2. Authentifizierung
Wikipedia definiert Authentifizierung wie folgt:

"Authentifizierung (griechisch αυθεντικός authentikós ‚echt‘, ‚Anführer‘; Stammform verbunden mit lateinisch facere ‚machen‘) ist der Nachweis (Verifizierung) einer behaupteten Eigenschaft einer Partei, die beispielsweise ein Mensch, ein Gerät, ein Dokument oder eine Information sein kann, und die dabei durch ihren Beitrag ihre Authentisierung durchführt."
http://de.wikipedia.org/wiki/Authentifizierung

Im SharePoint Umfeld bedeutet Authentifizierung also die Verifizierung eines Benutzer am System. Für eine erfolgreiche Konzeption sind die folgenden beiden Aspekte zur Verifizierung im Vorfeld zu betrachten:

• Technologie zur Verifizierung,
• Benutzerquelle.

Als Technologie zur Verifizierung werden in SharePoint verschiedene Möglichkeiten geboten. Natürlich bietet SharePoint die Möglichkeit der Windows Authentifizierung, bei der der aktuell am Computer angemeldete Benutzer vom Browser an das System übergeben wird. Diese häufig verwendete Methode hat den Vorteil, das der Benutzer bei den üblichen Browser-Einstellungen seine Anmeldedaten nicht erneut für die SharePoint-Webseite eingeben muss. Auch sind für die einfachste Art der Windows Authentifizierung - NTLM - keine weiteren Konfigurationsschritte notwendig. Weiterhin stellt SharePoint aber auch die Möglichkeit zur Verfügung, durch Konfiguration von sogenannten Membership- und Roleprovider eine andere Art der Authentifizierung zu verwenden. Bei dieser Möglichkeit wird das lokale Benutzerkonto nicht weitergegeben.
Jede dieser Möglichkeiten verifiziert die Benutzerdaten durch verschiedene Technologien, die natürlich verschiedene Vor- und Nachteile mit sich bringen können. Allen gemeinsam ist jedoch, dass die Benutzerdaten gegen eine Benutzerquelle geprüft werden müssen. Für die Windows Authentifizierung ist diese Quelle meist das Active Directory System des Unternehmens, über welches auch die Anmeldung des Benutzers am Computer verifiziert wird. Je nach Anwendung oder Sicherheitsstandard ist es jedoch notwendig, eine andere Benutzerquelle als das intern für Anmeldungen und Quelle für verschiedene Dienste verwendete Active Directory System , zu verwenden. Diese Quellen werden über die schon genannten Membership Provider angebunden. Solche Quellen können sein:

• Benutzerdatenbanken,
• LDAP Systeme,
• Windows Live ID,
• und viele weitere.

Da auch die Möglichkeit besteht, einen Membership Provider zu entwickeln, sind den Benutzerquellen kaum grenzen gesetzt!

Folgende Rahmenbedingungen müssen für einen anforderungsgerechten Einsatz allerdings bedacht werden:

1. Nur Membership Provider ermöglichen die sogenannte Forms Based Authentication. Dabei handelt es sich um eine ASPX-Loginmaske, die an das Design des Portals angepaßt werden kann und sich daher insbesondere für Internet- und Extranetauftritte eignet. Windows Authentifizierung verwendet hingegen immer ein Client-Popup, dass nicht im Design und in der Funktionalität angepasst werden kann. Beim Einsatz dieser Forms Based Authentifizierung wird allerdings niemals der am Computer angemeldete Benutzer an SharePoint weitergegeben. In Folge muss sich ein Benutzer immer gesondert an SharePoint anmelden.
2. Authentifizierungsmethoden werden pro Webanwendung im SharePoint konfiguriert und können somit nicht verschieden für verschiedene Sites innerhalb einer Webanwendung angelegt werden. Es ist durchaus möglich, verschiedene Methoden für eine Webanwendung einzurichten. Welche Methode SharePoint jedoch für einen Benutzer verwendet, wird durch die Zonen der Alternativen Zugriffszuordnung gesteuert - und somit also über die URL, über die der Benutzer die Webanwendung ansteuert. Möchte man dem Benutzer die Auswahl der Benutzerquelle beim öffnen des Portals ersparen, ist diese Beziehung 1:1 .
3. SharePoint legt für jeden technischen Benutzer einen internen, so genannten SPUser an. Dieses Benutzer wird zum Beispiel in den Personenspalten von SharePoint verwendet.
4. Bei der Personenauswahl im SharePoint - zum Beispiel zum setzen von Berechtigungen oder zuweisen von Aufgaben - wird der Benutzer aus der entsprechenden Quelle gewählt.

Aus diesen vier Punkte ergeben sich verschiedene "Fallen" bei der Konzeption, insbesondere bei Internet- oder Extranetszenarien, die Quellen für interne und externe Benutzer mischen. Verwendet ein Benutzer intern Windows Authentifizierung über eine interne URL um die Vorteile der Office Client Integration und der automatischen Anmeldung zu verwenden, von extern aber einen Membership Provider über eine externe URL, hat dieser eine Benutzer zwei Benutzerkonten für die gleiche SharePoint Seite. Die oft geäußerte Anforderungen, das Mitarbeiter von Zu hause über das Internet genau so arbeiten sollen wie von intern und nur ein Profil besitzt, läßt sich so kaum realisieren.

Wie dieses Beispiel zeigt, sollte die Einrichtung der Authentifizierung im Vorfeld gut durchdacht werden, damit man bei der Umsetzung von Anwendungen und Szenarien keine Anforderungen übersieht, die im Gegensatz zur Machbarkeit bei der SharePoint Authentifizierung stehen. Eine Konzeption zur Authentifizierung muss daher die folgenden Fragen für jede Webanwendung beantworten:

• Über welche Wege wird zugegriffen?
• Welche Benutzerquellen werden aus Anwendungs- und Sicherheitsgründen benötigt?
• Sind einem Benutzer zwei oder mehr Benutzerkonten ( SPUser ) zugeordnet? Wird damit eine Anforderung erfüllt oder nicht erfüllt?
• Erfüllt der gewählte Membership Provider die Anforderungen an die Benutzerquelle?

Die Klärung der Authentifizierung ist neben den Rollen die zweite Säule eines erfolgreichen Rollen- und Berechtigungskonzeptes für SharePoint. Neben der dritten Säule Autorisierung bleibt nur ein Fazit, um alle relevanten Themen zu behandeln.

Good luck,

Andreas

Document Sets und PowerShell

Seit SharePoint 201ß erfreut sich jeder SharePoint Administrator über die PowerShell. Viele Verwaltungsaufgaben lassen sich nun durch Skripts automatisieren, aber auch einmalige Konfigurationen und Lösungen lassen sich einrichten. Sehr gerne verwende ich die PowerShell zur Dokumentenmigration aus dem Filesystem oder zur Neustrukturierung. An die Grenzen der vorhanden Cmdlets bin ich bei dem neuen Feature der Dokumentenmappen gestoßen - dafür gibt es nämlich keine! Das Erzeugen oder Ändern von Dokumentenmappen ist durch die mitgelieferten Cmdlets nicht möglich. Daher findet Ihr im folgenden Skript die Möglichkeit, Dokumentenmappen mit der PowerShell über das Objektmodel von SharePoint in der PowerShell anzulegen.

1. ### Load SharePoint SnapIn   
2. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)   
3. {   
4.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
5. }   
6. ### Load SharePoint Object Model   
7. [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)   
8.   
9. ### Get web and list   
10. $web = Get-SPWeb http://myweb   
11. $list = $web.Lists["List with Document Sets"]   
12.   
13. ### Get Document Set Content Type from list   
14. $cType = $list.ContentTypes["Document Set Content Type Name"]   
15.   
16. ### Create Document Set Properties Hashtable   
17. [Hashtable]$docsetProperties = @{"DocumentSetDescription"="A Document Set"}   
18. $docsetProperties = @{"CustomColumn1"="Value 1"}   
19. $docsetProperties = @{"CustomColum2"="Value2"}   
20.     ### Add all your Columns for your Document Set   
21.   
22. ### Create new Document Set   
23. $newDocumentSet = [Microsoft.Office.DocumentManagement.DocumentSets.DocumentSet]::Create($list.RootFolder,"Document Set Title",$cType.Id,$docsetProperties)   
24. $web.Dispose()  

Die Spaltenwerte der Dokumentenmappe werden durch die ab Zeile 16 erstellte Hashtable angelegt. Dabei werden die internen Spaltennamen angegeben. Wichtig ist auch, dass man den Inhaltstyp ( Content Type ) $cType aus der Sammlung der Liste auswählt und nicht aus der Sammlung des Webs. Ansonsten wird anstatt einer Dokumentenmappe nur ein neuer Ordner erstellt.
Als weite Methoden unter [Microsoft.Office.DocumentManagement.DocumentSets.DocumentSet] steht noch folgendes zur Verfügung:

Document Set Methoden

Mehr Details zu den Methoden findet man auch in der MSDN hier . Mit diesem Handwerkszeug sollte nichts mehr zwischen der PowerShell und Dokumentenmappen stehen!

Good Luck,

Andreas

SharePoint - Rollen und Berechtigungen (1)

Jedes Projekt zur Einführung einer SharePoint Farm muss sich bei der Konzeption des späteren Betriebs die Frage nach Benutzerrollen und Benutzerberechtigungen stellen. Oft ist in der Vergangenheit vergessen worden, diese Frage zu thematisieren oder es ist nicht ausreichend geschehen. Die Folgen davon sind, dass die Berechtigungensvergabe von einem Administrator nicht mehr nachverfolgt werden kann oder einfache administrative Aufgaben nur unter enormen Aufwand von verschiedenen Fachbereichen wargenommen werden können. Daher möchte ich mit diesem Artikel eine Hilfestellung für jeden geben, der vor der Herausforderung steht, ein Rollen- und Berechtigungskonzept für den Betrieb eines SharePoint-Systems zu entwerfen. Grundsätzlich müssen für eine solche Konzeption drei Themen betrachtet und behandelt werden:

1. Rollen,
2. Authentifizierung,
3. Autorisierung.

Da diese Themen alle zusammen die Lesbarkeit in einem Artikel sprengen würden, werde ich diese in mehreren Artikeln veröffentlichen. In diesem Artikel beginne ich mit dem Thema "Rollen".

1. Rollen
Microsoft sieht in SharePoint verschiedene administrative Rollen vor, die durch technische Beschränkungen gegenseitig abgegrenzt werden können. In folgender Darstellung sind diese Rollen gezeigt.

Rollenpyramide

Die Darstellung als Pyramide dieser Rollen kommt ganz einfach daher, dass Rollen am oberen Ende der Pyramide durch Autorisierung wesentlich mehr Konfigurationsmöglichkeiten und -Verantwortung besitzen. So ist es zum Beispiel die Rolle "Zentraladministration", welche die Rollen "Dienstanwendung" oder "Websitesammlung" erst einsetzt. Im folgenden eine kurze Beschreibung der verschiedenen Rollen:

• Die Systemadministration verwaltet die Basisinfrastruktur der SharePoint Farm, also die Windows Server und das zugrundeliegende Datenbanksystem. Auch Systeme wie Network Load Balancing ( NLB ) oder Prozesse wie Lösungs - Deployment auf dem Produktivsystem fallen in den Aufgabenbereich der Systemadministration, da diese als lokale Administratoren auf den Systemen autorisiert sind. Diese Rolle wird in der Regel durch Mitarbeiter der IT besetzt und ist aufgrund der benötigten Fähigkeiten notwendig.
• Die Zentraladministration verwaltet - wie es der Name der Rolle schon vermuten lässt - die Sharepoint Zentraladministration. Für diese Rolle kommen nur SharePoint - Experten in Frage. Die Fähigkeiten übersteigen die umfassenden technischen Fähigkeiten in Bezug auf SharePoint Systeme in sofern, als dass diese Rolle ebenso die mit dem SharePoint System verfolgte Vision kennen muss. Sie verantworten letztendlich maßgeblich die entstehende Struktur des Systems.
• Die Administratoren einzelner Dienstanwendungen benötigen meist nur ein spezielles Fachwissen. Diese Rolle unterstützt die Zentraladministration bei der Verwaltung bestimmter Dienstanwendungen, die vor allem sehr viel Aufwand zur pflege verlangen als auch einen ausgeprägten, fachlichen Hintergrund. Diese Rollen müssen nicht unbedingt mit "neuen Namen" besetzt werden, doch bietet es sich häufig zur Verwaltung der Dienste Benutzerprofildienst, Suche und Verwaltete Metadaten an. Die Zentraladministration kann die entsprechende Rolle an - ausschließlich - der entsprechenden Dienstanwendung autorisieren.
• Die Administratoren von Websitesammlungen ist die Rolle, die beim Anlegen einer neuen Websitesammlung durch die Eingabe von "primären Websitesammlungsadministrator" und "sekundärem Websitesammlungsadministrator" autorisiert werden. Diese Rolle hat Vollzugriff auf jede Website innerhalb der Sammlung und ist somit oftmal der First Level Support für einzelne Websiteadministratoren. Diese Rolle benötigt ausgeprägte Fähigkeiten zur Verwaltung von Websitesammlungen, welche theoretisch durch einen "Power User" oder "Key User" erlangt werden können. Somit muss der Aufwand dieser Rolle nicht zwangsläufig durch die interne IT abgefangen werden - jedoch erfordert diese Rolle auch oft Kenntnis und Verantwortung über IT-Richtlinien. Zum Beispiel sind Adminsitratoren von Websitesammlungen autorisiert, Features für die gesamte Sammlung zu aktivieren.
• Die Administration einzelner Websites verursacht meist einen erheblichen Teil des Aufwandes, der zur Verwaltung eines SharePoint Portals notwendig ist. Die benötigten Fähigkeiten können einem "Power User" oder "Key User" durch Class Room Training an die Hand gegeben werden. Somit entfällt ein großer Teil des Aufwands zum Erstellen von Listen, Ansichten und Webparts auf die Fachabteilung die den "Key User". Allerdings muss bei diesem Szenario klar sein, dass die meisten dieser "Key User" IT-Richtlinien nicht beachten werden. Entweder stehen die Richtlinien im Weg oder sie werden einfach nicht verstanden. Wenn der Knopf da ist, warum soll ich ihn dann auch nicht drücken?

Die Verteilung dieser Rollen ist für die Projektplanung von großer Bedeutung, den die hier getroffenen Entscheidung sind oft von Dauer und beeinflussen die Akzeptanz und auch den Einführungsaufwand des Projekts maßgeblich! Daher stellt sich bei der Konzeption der Rollen folgende Frage:

"Welche Rollen werden zukünftig durch Key User wahrgenommen?"

Nehmen Key User die Rollen der Websitesammlungs- und Websiteadministratoren ein, schont das den Ressourceneinsatz von spezialisierten Fachkräften aus der IT. Andererseits erhöht sich der Initialaufwand des Projekts durch erhöhten Schulungsbedarf. Auch die Akzeptanz von Websites oder Dienste wie Metadaten und Suche steigt oftmals, wenn diese durch Key User und nicht durch die IT verwaltet werden. Diese Dienste leben davon, durch eine, dem Benutzer nahe, Fachabteilung beständig gepflegt zu werden.

Durch die Betrachtung der verschiedenen Rollen ist der Grundstein einer erfolgreichen SharePoint Rollen- und Berechtigungskonzeption gelegt. Folgende Themen müssen jedoch auch betrachtet und berücksichtigt werden:

• Authentifizierung,
• Autorisierung,
• Fazit.

Good luck,

Andreas

Review - AvePoint Certified Expert Training

Zwei Tage in dieser Woche durfte ich das AvePoint Certified Expert Training in der AvePoint Deutschland Niederlassung in München geniesen und möchte meine gesammelten Erfahrungen mit euch teilen. In diesem Artikel möchte ich einen ersten Überblick über die Produktpalette von AvePoint geben. Doch zuerst möchte ich mich an dieser Stelle noch einmal bei dem Team von AvePoint für die zwei Tage bedanken, die sowohl vom Rahemprogramm als auch von den Inhalten besser hätten nicht sein können! Nicht zuletzt habe ich es unserem Dozenten Michael Denzler zu verdanken, dass ich mich ab jetzt offiziell

nennen darf!

Doch nun zur Zusammenfassung. Die amerikanische Firma AvePoint ( www.avepoint.de ) ist mit einer Niederlassung in Deutschland vertreten und erweitert hier Ihr Netzwerk durch starke Partner - wie eben auch mit Data One ( http://www.dataone.de/de/unternehmen/partner/Seiten/AvePoint.aspx ). Den Firmennamen kennt der ein oder andere sicherlich schon von Veranstaltungen mit SharePoint als Thema - hier ist AvePoint eigentlich immer Vertreten und oft Sponsor. AvePoint setzt mit enormen Know-How die Power von SharePoint frei, wie es uns auch der Slogan "AvePoint - Unleashing the Power of SharePoint " deutlich macht. Hierfür wurden einige interessante Produkte unter der Produktfamilie "DocAve" entwickelt, die für jeden SharePoint- Anwender einen Blick wert sind:

• SharePoint Data Protection,
• SharePoint Administrator
• SharePoint Storage Optimization,
• SharePoint Migration,
• Sharepoint Compliance,
• SharePoint Reporting.

Ein zentraler "DocAve Manager", momentan in der Version 5, wird dabei auf einem Server im bereitgestellt und ist über eine Browser aufrufbar, so dass er von jedem Rechner zugegriffen werden kann. Dieser DocAve Manager verbindet dann die "DocAve Agents" und läßt so den Administrator mehrere Farmen und viele Server über eine Oberfläche betreuen.

DocAve Manager v5 Beispielseite

Alle Lösungen lassen sich über diese eine Oberfläche steuern - auch wenn manche der Lösungeneigene Webparts mit sich bringen, die direkt in SharePoint verwendet werden. Doch nun zu einer kleinen Beschreibung der Lösungen!

Data Protection

Die Lösungen von Data Protection haben ganz klar ein Ziel: SharePoint sichern und wiederherstellen. Der DocAve Restore Manager aus dieser Lösungsreihe ist eines der kostenlosen AvePoint Tools und ermöglicht es, aus "Offline"-Datenbanken oder Datenbanksicherungen einzelne SharePoint Elemente oder ganze Strukturen wiederherzustellen - ein Must Have für jeden Admin! DocAve Backup and Restore hingegen versetzt einen Adminsitrator in die Lage, seine Backup-Methoden "intelligenter" zu gestalten. So können Inhalte wahlweise mit oder ohne Blobs gesichert werden, die Sicherungen über Zyklen auf andere Speichermedien transportiert oder sogar durch die so genannte Criticallity Matrix eine variable Auswahl an Elemente in einem änderten Rhythmus anhand ihrer Wichtigkeit gesichert werden.

SharePoint Administrator

Ein Traum-Tool für jeden Admin! Einfach mal herausfinden, welche Berechtigungen ein Benutzer wo hat? Berechtigungen kopieren? Mehrere Subsites gleichzeitig anlegen und verwalten - kein Problem für den DocAve SharePoint Adminstrator! Auch Replication und Content Management fällt in diese Kategorie!

Storage Optimization

Blobs und große Datenmengen machen das System langsam, die Ablage teuer und ein Datenbank-Restore wird zur Wochenendbeschäftigung. Hier hilft der kostelose DocAve Extender, der Blobs aus der SharePoint Datenbank gefiltert per EBS oder RBS auf logische Geräte auslagert - und zwar kostenlos! Mit dem DocAve Archiver kann man das ganze dann sogar zeitgesteuert durchführen!

SharePoint Migration

AvePoint kann migrieren - und zwar so ziemlich alles was Inhalte hat nach SharePoint!

SharePoint Compilance

Mit AvePoint sind zertifizierte Prozesse in SharePoint möglich! Der DocAve SharePoint Vault macht unveränderbare Snapshots vom System, der DocAve Auditor sammelt Informationen über Änderungen an Dokumenten und DocAve eDiscovery ermöglicht das Suchen und exportieren von Inhalten mit bestimmten Schlagwörtern!

SharePoint Reporting

Mit dem DocAve SharePoint Monitor und dem DocAve Report Center kennt man seinen SharePoint - das betrifft die Hardware und Verfügbarkeit der Systeme ebenso wie das Wachstum der logischen Struktur.

Natürlich eignen sich diese kleinen Anrisse von mir nicht, sich einen tieferen Einblick in die Produkte zu verschaffen, aber ich hoffe den ein oder anderen damit auf die Spur einer Lösung gesetzt zu haben! Meiner Meinung nach unterstützen diese Produkte bei den wichtigsten Problemstellungen von Sharepoint, allen voran dem Dokumentenmanagement und der Handhabung großer Datenmengen. Gerade hier werden bei der Konfiguration von SharePoint Systemen die größten Fehler in der Planung gemacht!  Auch verringern die Tools den administrativen Aufwand für SharePoint Infrastrukturen erheblich und helfen somit, Kosten einzusparen!
Mir persönlich fällt kein Grund mehr ein, warum in einer SharePoint Infrastruktur DocAve zumindest mit den kostenlosen Tools vorhanden sein sollte.

Weitere Artikel über AvePoint Tools - coming soon...

Good luck,

Andreas

Nintex Live - Nintex Workflow aus der Wolke

Es ist wieder so weit - Nintex hat ein neues Spielzeug für uns! Nintex hat die Trends erkannt und uns etwas für die Wolke gebastelt - Nintex Live! Alle, die schon Nintex Workflow 2010 einsetzen, können nun verschiedene Dienste von Nintex und Partnern aus der Wolke konsumieren. Die auf Windows Azure implementierte Lösung stellt einen Katalog an Diensten bereit, die wie die schon bekannten Aktionen im Workflow Designer eingesetzt werden können. Letztendlich sind aber alle Aktionen nur Webservices, die durch die Aktion aufgerufen werden. Webservices bieten dabei Dienste an wie Statusupdates für soziale Netzwerke, Übersetzungen, Kontrolle der Flugdaten oder aber auch die Übergabe von Daten an einen Workflow in einer anderen Farm. Die folgende Darstellung verdeutlicht die hinterlegte Infrastruktur:

Da Partner den Nintex Live Katalog erweitern werden, wird es sich lohnen http://www.nintex.com/en-US/Products/Pages/NintexLive.aspx genauer anzuschauen!

Good luck,

Andreas