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

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

SharePoint Alternate Access Mapping URL Redirect

Hi,

AAM ( Alternate Access Mapping - Alternative Zugriffszuordnung ) URL Redirect ist ein interessantes Feature im SharePoint 2010, der eine Migration von SharePoint 2007 auf 2010 vor sich hat, die sich unter Umständen über einen längeren Zeitraum hinzieht. AAM URL Redirect wird immer dann interessant, wenn die neue SharePoint 2010 Farm die gleiche URL wie die alte 2007 Farm verwenden soll.
Häufiges Beispiel: http://intranet.company.com ist die produktiv 2007er Farm, die URL soll aber nach der Migration von der neuen 2010er Farm verwendet werden, es werden aber nicht alle Inhalt gleichzeitig migriert sondern Stück für Stück. Zwei Systeme und eine URL sind nur schwierig möglich und ein supportetes Szenario fällt mir für SharePoint nicht ein, auch wenn ich darüber noch nicht wirklich nachgedacht habe :-) Also bekommt das alte System eine andere URL - aber was ist dann mit den gespeicherten Links der Anwender in den Browserfavoriten, Emails etc...?
AAM Rerouting deckt dieses Szenario ab, indem man das neuen SharePoint 2010 System so konfiguriert, dass es Inhalte, die es selbst nicht beinhaltet und finden kann, unter einer anderen URL auf einem SharePoint 2007 System sucht.
http://technet.microsoft.com/en-us/library/ee720448.aspx stellt eine Doku zu AAM URL Redirect bereit, aber für Lesefaule hier eine kurze Zusammenfassung und den ein oder anderen Tipp, den man sich dort nicht anlesen kann. Folgendes Szeanrio:

Um dieses Szenario mit AAM URL Redirect umzusetzen, muss man eigentlich nur folgende Schritte tun:

1. Sobald das neue System verfügbar ist und erreichbar, ändert man zuerst die internen DNS Einträge, so dass http://intranet.company.com auf den neuen Server zeigt und http://old-intranet.company.com auf den alten Server.
2. Man ändert auf beiden Systemen - neu und alt - wie gewohnt die Einstellungen für alternative Zugriffszuordnung.
3. Man führt auf dem SharePoint 2010 Server folgenden STSADM Befehl aus:

STSADM.EXE  -o  addzoneurl  -url  http://intranet.company.com  -urlzone  Default  -zonemappedurl  http://intranet.company.com  -redirectionurl  http://old-intranet.company.com

Fertig! So einfach ist das! Am STSADM Befehl kann man erkennen, dass man für eine öffentliche URL im neuen SharePoint Portal einfach eine RedirectionUrl angeben soll. Falls man für eine Webanwendung mehrere öffentliche URLs konfiguriert hat, muss man den Befehl entsprechend oft und mit entsprechend geänderten Parametern ausführen.

 Was ich bisher wissenswertes über AAM URL Redirect herausfinden konnte ist:

• Die Inhaltssuche findet in der gemappten Zone des Alt-Systems statt, über alle Inhalte aller Site Collections in der Webanwendung.
• Es kann nur natürlich nur eine Redirection URL pro öffentlicher URL hinterlegt sein,
• Managed Paths auf dem alten System müssen auch auf dem neuen System angelegt werden, ansonsten funktioniert der Redirect nicht.
• Es muss sich nicht tatsächlich migrierten Inhalt handeln, der durch ein Migrationsverfahren ( Migration API oder Content Database Attach ) vom alten auf das neue System transportiert wurde, damit ein Redirect erfolgreich ist.

Falls ich noch was neues zum Thema AAM URL Redirect dazulernen darf, erweitere ich die Liste.

Bis dahin:

Good luck,

Andreas

Suchergebnisseite mit PowerShell setzen

Hi,

Websitesammlungen mit der PowerShell Scripts anzulegen ist eine gute Angewohnheit. Viele Einstellungen kann man nur oder am besten mit der PowerShell konfigurieren, so zum Beispiel die Inhaltsdatenbank oder das Taxonomy Feature. Meistens sind das Konfigurationen, die man für jede Websitesammlung konfigurieren möchte. Auch die Zielergebnisseite ist eine solche Einstellung, hat man doch in vielen Fällen ein, oft unter hohem Aufwand angepasstes, Suchcenter. Manuell kann man diese Einstellung in den Websiteeinstellungen unter "Sucheinstellungen" konfigurieren.

 Diese Einstellungen ist eine Property im SPWeb Objekt und kann, wie im folgenden Beispielskript, mit der PowerShell gesetzt werden:

1. $site = Get-SPSite -Identity "http://sitecollection"  
2. $web = $site.RootWeb   
3. $web.AllProperties["SRCH_TRAGET_RESULTS_PAGE"] = "/search/customresults.aspx"  
4. $web.Update()   
5. $web.dispose()  

Recht einfach also, diese Einstellung in seinen Skripten zu verwendet.
!!ACHTUNG!! Wer sich jetzt überlegt, dass ein SPWeb und seine Properties ja auch alle Subseiten sind und man auf diese Art eigene Ergebnisseiten für Sub-Seiten konfigurieren kann, was über die Oberfläche ja nicht möglich ist, der sollte wissen: JA, man KANN das Property auf jedem Subweb setzten. Interessiert nur den SharePoint nicht, der holt immer das Property vom Rootweb :-)

Good Luck,

Andreas

PDF und MSG Dateien in SharePoint 2010 öffnen - Browser File Handling

Immer wieder werde ich gefragt, wie man in SharePoint 2010 Adobe PDF Dateien denn "richtig" öffnen könne. Also, ohne vorher die Datei erst zu speichern oder ähnliches. Ein beliebtes Thema auf jedem SharePoint-Blog, hat man doch seit der 2010er Version von SharePoint die Möglichkeit, diese Einstellung in der Zentraladministration vorzunehmen. Und vor allem: Man kann mit der gleichen Einstellung auch MSG Dateien ( Outlook ) direkt öffnen. Das wird jeden freuen, der in der 2007er Version von SharePoint schon Outlook MIME Types in die Registry gefummelt hat. Nun Reihe ich mich aber mal brav bei anderen SharePoint Bloggern ein und trage die Kunde des Browser File Handlings in die Welt!
Die Problemstellung schaut wie folgt aus:

SharePoint möchte die Datei speichern oder abbrechen, bietet aber kein Öffnen- Button an. Das ist mit MSG Dateien übrigens das Gleiche. Ändern kann man das Verhalten in der Zentraladministration.Von der Startseite aus geht man auf "Web Applications", markiert die entsprechende Webanwendung und klick "General Settings" oben im Ribbon. In der darauf folgenden Konfiguration ändert man die Einstellung "Browser File Handling" von "Strict" auf "Permissive" um.

Bestätigt man den Dialog, werden PDF-Dateien zukünftig im Browser direkt geöffnet und bei MSG Dateien aus gibt es den "Öffnen" Knopf.

Keine Frage -  man verändert mit diesen Einstellungen die Sicherheitseinstellungen des Servers und lockert diese. Für alle, die das nicht interessiert hab ich noch ein kleines PowerShell Skript, dass die Arbeit für jede Webanwendung automatisch erledigt :-)

1. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null){   
2.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
3. }   
4.   
5. foreach($webApp in Get-SPWebApplication){   
6.     if ($webApp.BrowserFileHandling -eq "Strict") {   
7.         $webApp.BrowserFileHandling = "Permissive"  
8.         $webApp.Update()   
9.     }   
10. }  

Good luck,

Andreas

Claims Based Authentication, IIS 401 und Access Denied.

Claims Based Authentication ( CBA ) - Authentifizierung der nächsten Dimension, neu, toll und das beste: es gibt keinen Grund es NICHT zu tun!!! Sagt zumindest Microsoft, ich zitiere:

There are no additional steps to implement Windows authentication when you use the claims-based authentication mode.

So Stand es zumindest zum Veröffentlichung-Datum dieses Artikels auf TechNet geschrieben. Leider muss diese Prophezeiung erst noch in Erfüllung gehen. Ich wurde die letzten Tage doch ziemlich arg von der CBA gebeutelt. Ich brauche Forms zur Anmeldung, das funktioniert nur mit CBA. Was tun, wenn die CBA Windows integriert nicht funktioniert?
Die Problemstellung ist, das Benutzer vom IIS einen HTTP Fehler 401 bekommen, wenn Sie auf SharePoint zugreifen. Access Denied vom IIS, nicht vom SharePoint. Zugreifen können Benutzer das Portal über verschiedene URLs, http://1111, https://1111,  http://1111.domain.local usw. und so fort. Mein Alternate Access Mapping sah dabei wie folgt aus:

 

Jede URL ist in einer eigenen Zone. Nachstellen konnte ich, dass die Authentifizierung immer nur über eine dieser URLs funktioniert hat, und zwar:

• Für jeden Nutzer die gleiche URL,
• Bis zum nächsten IIS Reset, 
• Nach einem IIS Reset funktioniert der Zugriff über eine zufällige URL.

 Nach Stunden des Troubleshootings habe ich folgendes Alternate Access Mapping ausgetestet:

  Alle URLs sind auf eine Zone eingetragen ( "Add Internal URLs" ). Und siehe da, die Authentifizierung funktioniert über jede URL! Da in der Zwischenzeit der Microsoft Support eingeschaltet war und das Problem nicht kannte/ lösen konnte, bleibt mir nur der Schluss: Es ist ein Bug, eine Windows Authentifizierung mit CBA, die einen Zonen-Wechsel nicht verkraftet kann nicht "Work as designed" sein! Das waren meine Rahmenbedingungen:

• Es handelt sich um eine SharePoint Farm, allerdings nur ein Web Frontend Server,
• Stand CU Dezember 2010,
• Classic Authentifizierung funktionierte ohne Probleme,
• Problem trat sowohl bei NTLM als auch bei Kerberos auf

Für meine Lösung reicht der "Workaround" aus dem zweiten Screenshot, zumindest in diesem Fall. Mehr Zeit möchte ich auch nicht in weiteres Troubleshooting zum weiteren Eingrenzen des Problems investieren. Sollte ein kommendes CU den Fehler beheben, werde ich es vermerken. Sollte jemand von euch weitere Infos zu diesem Problem haben, freue ich mich über jedes Kommentar. Falls nicht hoffe ich, dass ich dem ein oder anderen wenigsten einige Stunden Troubleshooting ersparen kann!

Good Luck,

Andreas

User Properties mit PowerShell anlegen und bearbeiten

Aus der Not geboren ( Die Not hat den Namen "CU December" und ich habe mich in diesem Post schon darüber ausgeheult :-) ) habe ich mich damit beschäftigt, wie man denn eigene User Properties in User Profiles automatisch befüllen und erstellen kann. Als Nicht- Developer und Admin denke ich dabei natürlich immer zuerst an die PowerShell! Dumm nur dass Microsoft offensichtlich vergessen hat uns dafür die nötigen Befehle direkt für die PowerShell einzupacken. Seltsam, da sich sicher jeder, der schon einmal die überwältigend träge, hässliche, langsame und undhandliche Maske zum administrieren der User Properties in SharePoint noch nie sehnlicher ein Power Shell- Skript gewünscht hat.

User Property Administration - ein Administrations-Alptraum wie aus den frühen 90ern.

Wir müssen uns des Objektmodells bedienen, um diese Eigenschaften über die PowerShell verwalten zu können. Die benötigte Klasse hierfür ist UserProfilManager ( http://msdn.microsoft.com/en-us/library/microsoft.office.server.userprofiles.userprofilemanager.aspx ).
Bauen wir uns also ein Skript, beginnen wir mit dem laden der SharePoint cmdlets und dem erstellen eines UserProfileManager-Objekts. Dieses Objekt beinhaltet alle Profile und Properties aus der Service Application, die im Kontext der angegebenen Seite verwendet wird.

1. # Load Sharepoint SnapIn      
2. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)      
3. {      
4.     Add-PSSnapin Microsoft.SharePoint.PowerShell      
5. }     
6.     
7. # Create Service Context      
8. $site = Get-SPSite http://mySiteHostUrl      
9. $serviceContext = Get-SPServiceContext $site     
10.     
11. # Get ProfileManager, User Profiles and User Properties      
12. $profileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($serviceContext)      
13. $userProfiles = $profileManager.GetEnumerator()      
14. $properties = $profileManager.get_Properties()   

Nun haben wir eigentlich alles was wir dazu benötigen, neue User Properties anzulegen und bestehende Profile zu befüllen. Neue User Properties kann man wie folgt anlegen:

1. # Create new Property   
2. [Microsoft.Office.Server.UserProfiles.Property]$property = $properties.Create($false)   
3. # Set property vaules   
4. $property.set_Name("Property Name")   
5. $property.set_Description("Property Description")   
6. $property.set_DisplayName("Property Displayname")   
7. $property.set_IsUserEditable($true)   
8. $property.set_IsVisibleOnEditor($true)   
9. $property.set_IsVisibleOnViewer($true)   
10. $property.set_Type(String)   
11. $property.set_Length(255)   
12. # set other values you need...   
13. $property.Commit()   
14. # Add new Property to Repository   
15. $properties.Add($property)  

Denkbar einfach, so eine property anzulegen, wenn man erstmal ein ProfileManagerObjekt hat. Das wichtigste hierbei ist eigentlich, den richtigen Typ ( set_Type() ) zu wählen ( String, Multi Value, etc...). Fast noch einfacher ist es dann, das User Property für jedes Profil befüllen zu lassen.

1. foreach($userProfile in $userProfiles)   
2. {   
3.     # Set New Value   
4.     $userProfile["Property Name"].Add("New Value")   
5.     $userProfile.Commit()   
6. }  

Ein solches Skript, vielleicht noch ein geplanter Windows Task und dazu die nötige Phantasie sollten eigentlich eine nützliche Lösung ergeben können :-) Viel Spaß damit!

Good luck,

Andreas

CU Dezember, NetBiosEnabled, User Profile Sync und MIISRCW: System.NullReferenceExeption <- Neue Erkenntnisse

SOLVED WITH
CU FEBRURARY 20100

Na, NetBiosName unterschiedlich vom FQDN? Benutzerprofilsynchronisations-Dienstanwendung für den Import des NetBios Names aktiviert? Aktuell CU December installiert? Neue Import Connection notwendig? Pech gehabt! :-) Seit CU December dankt SharePoint das mit der Meldung Unable to process Create message ( oder Unable to process Put message wenn man versucht, eine bestehende Verbindung zu ändern ). Im Event Log sieht man dann eine Event ID 3:

ERROR:
"Unable to process create message"
EVENT LOG:
Forefront Identity Manager: Event ID 3
----------------------------------------------
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri}
MIISRCW: System.NullReferenceException: Object reference not set to an instance of an object.
   at MIISRCW.IMMSMAUtility.UIGetData(String pszRequestInformation, Int32& pfSuccess, String& ppszResult)
   at Microsoft.ResourceManagement.SyncConfig.TryGetSchema(String maType, String initializationString, String& returnString)
   at Microsoft.ResourceManagement.ActionProcessor.SyncConfigActionProcessor.Create(String typeName, IList`1 createParameters, Guid creator, Guid cause)
   at Microsoft.ResourceManagement.ActionProcessor.SyncConfigActionProcessor.ProcessInputRequest(RequestType request)
   at Microsoft.ResourceManagement.ActionProcessor.ActionDispatcher.ProcessInputRequest(RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction(RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.ExecuteAction[ResponseBodyType](RequestType request)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request, Guid requestIdentifier, Object redispatchSingleInstanceKey)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.DispatchRequest[ResponseBodyType](RequestType request)
   at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Create(Message request)

Na, da bleibt wohl nur das hoffen auf das nächste CU oder SP ( lt. diesem Forenverlauf stehts sogar seit 14. Februar auf der Liste von MS http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/e08b9564-05c0-4791-b8a2-e589834c4b7c ). Obwohl, langsam schleicht sich so ein unangenehmes Gefühl beim einspielen ein....

Good luck und immer auf dem neusten Patch-Level bleiben, höhöhö,


Andreas


P.S.: Wer nun wegen Terminen doch ne schnelle Lösung braucht: Wenn man den Account Name im Profil manuell ändert, wird er beim inkrementellen Import nicht mehr geändert...

Duet Enterprise for SharePoint and SAP

Vorbei ist er - der Virtual Launch Event zu Duet Enterprise for SharePoint und SAP am 01. Februar 2010! Dabei sollte keiner, der sich schon den Kopf über SAP und SharePoint in der gleichen Problemstellung zerbrochen hat, sich voraussichtlich noch zerbrechen wird oder sich den Kopf von anderen Leuten darüber zerbrechen wird, dieses Event verpaßt haben. Ups, doch verpaßt? :-) Nicht schlimm, schnell hier anschauen:

http://www.duetenterprisesummit.com/SitePages/Agenda.aspx

Noch nie etwas von Duet Enterprise gehört? Das ist schnell erklärt:

Das, was Duet Enterprise ausmacht ist der Pfeil zwischen SAP NetWeaver und SharePoint. Der verbindet nämlich das Duet Enterprise SAP Add-on mit dem Duet Eterprise SharePoint Add-on. Und das bietet tolle Vorteile für ansonsten Recht interessante Dinge wie:

• Single Sign On SAP Benutzer und Windows Benutzer,
• Business Connectivity Services Entitäten OOTB, 
• ...

 Somit sollte man in der Lage sein, ziemlich schnell sowas wie unten auf dem Bild zu basteln:

SAP HR, Empoyee Self Services in SharePoint? Kein Problem, Duet Enterprise ist ja jetzt mehr Framework als fertige Prozesse aus Duet 3.5 Zeiten... Also, schnell noch den Virtual Launch Event anschauen!

Good luck,

Andreas

Dokumente von Filesystem automatisch nach SharePoint importieren

Hallo zusammen,

anbei ein kleines PowerShell Skript, dass alle Dateien aus einem Ordner des Filesystems in eine SharePoint Liste importiert. Mir hat das Skript schon oft geholfen, ob als Hilfe für Datenmigration oder ob als geplanter Windows Tasks, der frisch eingescannte Dokumente regelmäßig importiert. Natürlich ist es möglich, automatisch Metadaten an die neu nach SharePoint hinzugefügten Dokumente anzufügen oder den Ersteller oder das Erstellungs-Datum vom Filesystem nach SharePoint zu importieren - aber Ihr werdet da schon die nötige Phantasie mitbringen :-)

1. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)   
2. {   
3.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
4. }   
5.   
6. $web = Get-SPWeb -Identity "http://sites/web/" ### Set your web URL   
7. $folder = $web.GetFolder("http://site/web/list") ### Set your List URL here   
8.   
9.     foreach ($file in Get-ChildItem -Path "c:\folderwithdocuments") ### Set the location path of the folder with the documents here   
10.     {   
11.         $bytes  = [System.IO.File]::ReadAllBytes($file.Fullname)   
12.         $SPDoc = $folder.Files.Add($file.Name,$bytes,$true)   
13.         $SPDoc.Update()   
14.         WRITE-HOST $file.FullName + " successfully added!" -ForegroundColor Green   
15.     }   
16. $web.Dispose()  

Ich hoffe es hilft!

Good luck,

Andreas

SharePoint Cumulative Update ( CU ) December

Das CU Dezember für SharePoint 2010 ist nun schon ein paar Wochen verfügbar. Finden tut man das ganze unter der offiziellen Microsoft Seite Updates for SharePoint 2010 Products. Dort kann man sich immer das neuste Material herunterladen. Den Post schreib ich aber nur, um euch auf den folgenden Satz aufmerksam zu machen, der unter dem CU December steht:

Note: You must restart the User Profile Synchronization service after installing this cumulative update. For more information see the Start the User Profile Synchronization service section in the Configure profile synchronization article in the library.

Also nicht vergessen, den Benutzerprofil-Synchronisationsdienst neu zu starten!

Good luck,

Andreas

P.S.: Schon gewußt, dass man den Konfig-Wizard nach der Installation von CUs und SPs nicht mehr nach einander auf jedem Server ausführen muss? Einfach

psconfig –cmd upgrade –inplace b2b -wait

auf jedem Server in der Kommando-Zeile aufrufen!

Office Web Apps Administration

Hi,

alle wichtigen Office Dokumente im Browser anschauen - unabhängig von der Client Version. Mit Office Web Apps und SharePoint 2010 ist dieses Szenario sehr einfach realisiert. Die Installation und Konfiguration der Dienstanwendungen in SharePoint ist kein nennenswerter Aufwand. Auch die Administration ist für einen SharePoint Admin keine sehr großer Bedrohung - wenn man denn weiß was zu tun ist :-) Eine der Stellschrauben, die all zu oft vergessen werden ist der Cache der Office Web Apps. Office Web Apps laden jedes aufgerufene Dokument in den Cache - das erhöht die Geschwindigkeit des Renderings wesentlich! Nun kann man sich vorstellen, dass der Cache recht schnell einiges an Platz auf der Platte nimmt. Diesen Platz gilt es im Auge und unter Kontrolle zu halten!
Dafür gibt es einen lesenswerten TechNet Artikel. Zusammengefasst gilt es folgendes zu beachten:

• Der Cache wird einmal pro Webanwendung angelegt,
• der Cache wird automatisch in eine Websitesammlung abgelegt und somit in eine SharePoint Inhaltsdatenbank.

Eingestellt werden kann am Office Web Apps Cache:

• Die maximale Größe,
• das Ablaufdatum.

Mit beiden Einstellungen kann man schon dafür sorgen, dass einem der Cache nicht über den Kopf wächst. Nun will man den Cache aber auch nicht unbedingt in seiner produktiven Inhaltsdatenbank und somit auf seinen Datenbanksicherungen. Daher sollte in der Routine zum Anlegen einer neuen Webanwendung direkt enthalten sein, den Office Web Apps Cache in eine eigene Inhaltsdatenbank umzuziehen. Das kann man natürlich mit der PowerShell erledigen ( wie es der Artikel schon sehr gut beschreibt ).

Ich habe mir folgendes Skript daraus geschrieben, mit dem jeder Admin in der Lage sein sollte, die Wartung des Web Apps Caches vorzunehmen ohne sich die einzelnen Befehle suchen und bearbeiten zu müssen.

1. if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)   
2. {   
3.     Add-PSSnapin Microsoft.SharePoint.PowerShell   
4. }   
5.   
6.     $webAppUrl = Read-Host "URL of the Webapplication"  
7.     $DBServer = Read-Host "Database Server"  
8.     $CacheSize = Read-Host "Max Cache Size GB"  
9.     $expirationDays = Read-Host "Expiration Period in Days"  
10.        
11.     Write-Host "..."  
12.     Write-Host "Your Web Application: " -nonewline; Write-Host $webAppUrl -ForegroundColor Yellow    
13.     Write-Host "Your Database Server: " -nonewline; Write-Host $DBServer -ForegroundColor Yellow    
14.     Write-Host "Your Cache Size in GB: " -nonewline; Write-Host $CacheSize -ForegroundColor Yellow   
15.     Write-Host "Your Expiration Time in days: " -nonewline; Write-Host $expirationDays -ForegroundColor Yellow   
16.     Write-Host "..."  
17.     $continue = Read-Host "Please confirm your input (y/n)"  
18.   
19.     if($continue -eq "y")   
20.     {   
21.         $webapp = Get-SPWebApplication -Identity $webAppUrl   
22.         $DBName = "WSS_CONTENT_OfficeWebAppsCache_" + $webApp.Name   
23.   
24.         $newDB = New-SPContentDatabase -Name $DBName -WebApplication $webAppUrl -DatabaseServer $DBServer -MaxSiteCount 1 -WarningSiteCount 0   
25.         Write-Host "New Content DB " -nonewline; Write-Host $DBname -ForegroundColor Yellow -NoNewline; Write-Host " created for Web Application " -nonewline; Write-Host $webapp.Name -ForegroundColor Yellow -NoNewline; Write-Host " on Database Server " -nonewline; Write-Host $DBServer -ForegroundColor Yellow -NoNewline; Write-Host "..."  
26.         Get-SPOfficeWebAppsCache -WebApplication $webAppUrl | Move-SPSite -DestinationDatabase $newDB   
27.         Write-Host "Move Office WebApps Cache Site Collection successfully to new ContentDB..."  
28.         $GBSizeInBytes = 1024 * 1024 * 1024 * $CacheSize   
29.         Get-SPWebApplication | Set-SPOfficeWebAppsCache -ExpirationPeriodInDays $expirationDays -MaxSizeInBytes $GBSizeInBytes   
30.         Write-Host "Cache Byte Limit is set to " -nonewline; Write-Host $GBSizeInBytes -ForegroundColor Yellow -NoNewline; Write-Host " and Expiration Time to " -nonewline; Write-Host $expirationDays -ForegroundColor Yellow -NoNewline; Write-Host " days..."  
31.         Write-Host "Operation completed successfully..." -ForegroundColor Green   
32.     }   
33.     else  
34.     {   
35.         Write-Host "The operation was chanceled by user input..." -ForegroundColor Red   
36.     }   

Greift zu und speichert das Skript einfach als PS1 Datei ab. Aufrufen könnt Ihr es dann in der PowerShell mit dem Befehl C:\<Pfad>\<Dateiname>.ps1 .


Hoffentlich hilfts :-)

Good luck,

Andreas