SharePoint und Remote Blob Storage - Sinn und Unsinn.

Wer Heute eine SharePoint Plattform betreibt, muss sich früher oder später mit dem Thema Remote Blob Storage ( RBS ) auseinandersetzen. RBS meint die Auslagerung der großen Datentypen "Blob" aus der SQL Datenbank auf ein Filesystem. Diese kurze Beschreibung lässt vermuten, dass es sich dabei um ein Thema dreht, mit dem sich ausschließlich Administratoren und IT PROs auseinandersetzen. Als Entscheidungsgrundlage werden oftmals von Microsoft veröffentlichte TechNet Artikel zu Rate gezogen.

Die Vorteile durch den Einsatz von RBS lassen sich wie folgt zusammenfassen:

• Bei einer Filegröße von einem MB oder größer erhöht sich die Performance des I/O und der des Prozessors des Datenbanksystems.
• Operationen zum Betrieb der Datenbank wie dbcc checks oder Indexdefragmentierung sind wesentlich beschleunigt.
• Die Speicherkosten der Datenmengen können durch die Auslagerung auf einen Storage minimiert werden.
• Es sind Inhaltsdatenbankgrößen von mehr als 200 GB möglich.
• Es sind mehr Sicherungs- und Wiederherstellungsszenarien zur Einhaltung von SLAs möglich.

Die Nachteile eines RBS Einsatzes sind:

• Die Sicherungs- und Wiederherstellungsszenarien müssen betrachtet werden ( die Sicherungs- und Widerherstellungsszenarien müssen betrachtet werden - ein Nachteil, hat man keine Probleme beim Einhalten der SLAs ).
• Ein einmaliger Einrichtungsaufwand entsteht, bei dem nicht nur das reine "aktivieren" des RBS zu betrachten ist, sondern auch viele benötigte Szenarien wie Inhaltsveröffentlichung oder Qualitätssicherungsprozesse.
• Der Betrieb der Plattform wird durch den zusätzlichen Betriebsaufwand durch RBS teurer.

Auch wenn die Angaben wie immer ohne Gewähr sind und erfrischend arm an Details, ist der Administrator aufgrund dieser Information geneigt, sich mit Auswertungen über die Verteilung seiner Dateitypen und -größen zurückzuziehen und zu entscheiden, ob RBS für Ihn und seine Plattform sinnvoll ist oder nicht. Und genau das ist allzu oft der Fehler - denn oftmals kann der Administrator nicht alleine diese Entscheidung treffen. Ich sage:

"Remote Blob Storage wird in den meisten Fällen wegen Geschäftsanforderungen eingesetzt!"

Betrachten wir den essentiellen Kern der SharePoint Plattform - den Endanwender und dessen Interessenvertretung, den Website Administrator - ist die Problemstellung, die es zu lösen gilt, schnell gefunden. Es ist die Größe der Inhaltsdatenbank.
Die Inhaltsdatenbank ist in ihrer Größe beschränkt. Natürlich ist der Einsatz von mehreren dieser Inhaltsdatenbanken im SharePoint möglich, doch ist das kleinste Objekt, welches sich einer Inhaltsdatenbank zuweisen lässt, eine Websitesammlung. Eine Websitesammlung ist eine hieraschische Struktur von Webseiten, Bibliotheken und Dokumenten und hat das Potenzial, viele Inhalte zu beinhalten. Eine Websitesammlung kann jedoch nicht über mehrere Inhaltsdatenbanken verteilt werden. Hat eine Websitesammlung - zum Beispiel das Intranet eines Unternehmens oder die Projektseiten - eine gewachsene Struktur, können die 200 GB an Inhalt schnell überschritten werden. Die folgende Abbildung veranschaulicht eine solche Websitesammlung mit einer breiten Struktur.

Eine Inhaltsdatenbank enthält die gesamte Breite der Struktur. Um die Inhalte auf verschiedene Datenbanken zu verteilen, wird diese Struktur aufgebrochen.

Durch entsprechende Richtlinien im IT-Konzept und Quotierung lassen sich solche verteilte Website-Strukturen erreichen, jedoch zum Preis der Websitesammlungskonfiguration. Viele Einstellungen sind auf den Bereich einer Websitesammlung begrenzt. Diese Einstellungen sind zum Beispiel Inhaltstypen, SharePoint Benutzergruppen, Sucheinstellungen und viele mehr.

Um eben diese einfache und einheitliche Konfiguration den Websitesammlungsadministratoren zu ermöglichen und dennoch den sicheren Betrieb der SharePoint Plattform zu gewährleisten wird RBS eingesetzt. RBS ermöglicht einen Entwurf der SharePoint Plattform, der den Geschäftsanforderungen entgegen kommt.

Good luck,

Andreas

Share One 2012 - SharePoint Event

Die Share One wird seit 2010 veranstaltet und mach nach Köln und Zürich dieses Jahr in Frankfurt Station. Die Share One 2012 bleibt Ihrem Format treu und ist ein eintägiges Event rund um SharePoint. Interessante Vorträge von den Sponsoren AvePoint und Materna werden durch Erfahrungsberichte und Vorträge von namenhaften Speakern abgerundet.

Save the date!

Was:     www.shareone.de
Wo:      Lindner Hotel & Sports Academy Frankfurt
Wann:  09. Mai 2012


Beste Grüße,

Andreas

SharePoint - Rollen und Berechtigungen (4)

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. Dieser vierte Artikel schließt nach den ersten drei Artikeln

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

mit dem Fazit ab.

Fazit

"Bei einer ganzheitlichen Betrachtung aller relevanten Themen zu Rollen- und Berechtigungen zeigt sich auf den ersten Blick eine stimmige Best Practice"

Bei einer ganzheitlichen Betrachtung aller relevanten Themen zu Rollen- und Berechtigungen zeigt sich auf den ersten Blick eine stimmige Best Practice, die sich über die Themengebiete Rollen, Authentifizierung und Autorisierung erstreckt und eine Antwort auf die sich ergebenden Fragen liefert. Die konsequente Verwendung von Gruppen zur Autorisierung ermöglicht in Verbindung mit der Entkopplung von organisatorisch strukturierten Gruppen im Verzeichnisdienst und funktional strukturierten Gruppen in SharePoint die beste Anwendbarkeit und dementsprechend auch die maximale Einsparung am Aufwand. Außerdem ist in den meisten Fällen nur durch die zuvor erwähnte Entkopplung gewährleistet, dass Verantwortlichkeiten mit der richtigen Kompetenz umgesetzt werden und sich diese nicht übermäßig überschneiden. Ein Websiteadministrator hat auch weiterhin keine Verantwortung für die laufenden Wartungsarbeiten aufgrund organisatorischer Veränderungen, ein Administrator des Verzeichnisdienstes hingegen benötigt auch weiterhin nicht die Kompetenz zu entscheiden, ob die vom Ihm angelegten Gruppen nun auf bestimmten SharePoint Seiten berechtigt werden oder nicht.

"[...] je mehr Website Administratoren dementsprechend eingesetzt werden, desto weniger lässt sich die Best Practice durchsetzen."

Jedoch setzt diese Best Practice in der Praxis optimale Umsetzung der Empfehlungen voraus, die sich auf technischer Ebene nicht durchsetzen lassen. Auf fachlicher Ebene lassen sich die benötigten Kompromisse zur Umsetzung der Best Practice nur zu einem gewissen Grad realisieren. Technisch gesehen ist es nicht zu vermeiden, dass anstatt der organisatorisch strukturierten Gruppen aus dem Verzeichnisdienst einzelne Benutzer in SharePoint direkt berechtigt werden. Auch mit entsprechender Schulung der Website Administratoren kann man nicht garantieren, dass die Empfehlungen eingehalten werden. Auf der anderen Seite stellt es eben für die fachlich kompetenten Website Administratoren ein nicht immer akzeptierter Kompromiss dar, immer komplette organisatorisch strukturierte Gruppen zu verwenden. Oftmals soll ein Personenkreis berechtigt werden, der noch nicht in einer Gruppe organisiert ist. In jeder Betriebsphase einer SharePoint Farm wird daher die Best Practice mehr oder weniger nicht eingehalten werden. Je größer die Farm wird und je mehr Website Administratoren dementsprechend eingesetzt werden, desto weniger lässt sich die Best Practice durchsetzen.

"Die in den vorangegangenen Artikeln erläuterte Best Practice hilft, hat allerdings auch Schwachstellen"

Wie Eingangs der Artikelreihe erwähnt ist das Berechtigungskonzept bei vielen Betriebskonzepten einer SharePoint Farm ein Schwachpunkt, der nicht oder unzureichend betrachtet wurde. Das resultierende Ergebnis waren SharePoint Administratoren, die kaum in der Lage sind, Benutzerberechtigungen zu klonen oder effektiv herauszufinden. Die in den vorangegangenen Artikeln erläuterte Best Practice hilft, hat allerdings auch Schwachstellen.

"Ein in der Praxis bewährtes Tool hierfür ist das DocAve SharePoint Administrator der Firma AvePoint"

Die Empfehlung kann daher nur sein, die Best Practice zwar zu ermöglichen und zu schulen, sich als SharePoint Administrator aber nicht darauf zu verlassen. Die Schwachstellen kompensiert man als SharePoint Administrator mit erheblichem Aufwand zur Bewältigung von administrativen Aufgaben bezüglich Rollen- und Berechtigungskonzept, indem man mit einem Administrator des Verzeichnisdiensts und Power Shell die Anforderungen abdeckt oder durch Einsatz von zusätzlichen Tools. Die häufigsten dieser administrativen Anforderungen sind sicherlich das Auflisten der effektiven Berechtigungen eines Benutzer oder das Kopieren der effektiven Rechte von einem auf den anderen Benutzer.
Ein in der Praxis bewährtes Tool hierfür ist das DocAve SharePoint Administrator der Firma AvePoint. Dieser unterstützt den SharePoint Administrator bei alltäglichen administrativen Aufgaben, nicht nur aus dem Bereich „Rollen- und Berechtigungskonzept“, sondern auch beim Anlegen ganzer Websitestrukturen und Arbeiten mit Galarieinhalten wie Inhaltstypen. Vergleicht man den benötigten Aufwand für solche administrative Aufgaben ohne Tools zur Unterstützung, lohnt sich deren Lizenzierung schon recht schnell bei dem Einsatz einer SharePoint Farm mittlerer Größe.

Good Luck,

Andreas

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