Schlagwort-Archive: PowerShell

Office 365 Groups Governance – Teil 2

Im ersten Teil der O365 Groups Governance haben wir uns aus der Business Perspektive angeschaut, welche Groups Standardeinstellungen problematisch sind und mit welchem Ansatz man diese Probleme lösen kann. Heute gehen wir ins Detail und dafür habe ich mir folgende Agenda überlegt:

  1. Gruppenvorlagen
  2. Gruppenersteller einschränken mit einer neuen Groups-Vorlage
  3. Gruppenersteller einschränken durch Anpassen einer Gruppenvorlage
  4. Klassifizierung
  5. Namenskonventionen
  6. Berechtigungen Einschränken
  7. Speicherplatz beschränken

Das Ändern und Definieren neuer Standardwerte für Gruppenvorlagen, die für eine starke Unternehmens-Governance besser geeignet sind,  ist nur über die Online PowerShell-Konsole möglich. GANZ WICHTIG ist hierbei, dass das aktuellste Microsoft Azure AD PowerShell Modul (Version 1.1.166.0) nicht mehr die Befehle enthält, die es braucht, um die Gruppeneinstellungen anzupassen. Stattdessen gibt es diese nur in der vorherigen Version 1.1.130.0. Solltet ihr also bereits auf der neueren Version sein, müsst ihr diese über die Systemsteuerung wieder deinstallieren und die ältere Version installieren. Einen Download Link zu beiden Versionen findet ihr hier:
http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

Haben wir dies erledigt, so müssen wir uns zunächst wieder auf unseren Tenant verbinden. Die nötigen Befehle findet ihr im 6. Türchen meines #O365Adventskalenders.

1. Gruppenvorlagen:

Ähnlich wie auch unsere SharePoint Bibliotheken oder Seiten auf Vorlagen basieren, so ist dies auch für die Office 365 Groups der Fall. Über den nur in der Version 1.1.130.0 enthaltenen Befehl New-MsolAllSettingTemplate können wir auf die „Group.Unified“ Vorlage zugreifen und mehr Informationen erhalten.

O365 Groups Governance New-MsolAllSettingTemplate

Noch weiter im Detail können wir herausfinden, welche Werte überhaupt für so eine Vorlage definiert werden können:

O365 Groups Governance Werte der Vorlage

Das Problem hierbei ist jedoch, dass wir wirklich nur diese eine Vorlage haben. In Hinblick auf die verfügbaren PowerShell Befehle können wir zwar theoretisch auch eine neue Vorlage erstellen, ist aber bereits eine vorhanden, so erhalten wir eine Fehlermeldung. Die Architektur beim Erstellen von Gruppen gibt es außerdem noch nicht her, dass wir aus verschiedenen Vorlagen wählen können. Dies können derzeit nur Drittanbieter. Zur Vollständigkeit nachfolgend kurz das Vorgehen, um eine neue Vorlage zu erstellen. Anschließend beziehe ich mich aber nur auf das Anpassen der Werte der bereits existierenden Vorlage.

2. Gruppenersteller einschränken mit einer neuen Groups-Vorlage:

Falls ihr die existierende Groups-Vorlage über Remove-MsolSettings gelöscht habt, sind im Folgenden zur Information die Befehle, um auf eine neue Vorlage schreiben zu können. Dabei referenziere ich auf die $template – Variable aus dem Screenshot oben und deaktiviere das Gruppenerstellen als Ganzes, aber erlaube nur einer bestimmten Gruppe weiterhin das Erstellen. Das Erstellen dieser AD Sicherheitsgruppe und die Identifikation ihrer GUID geht mit folgenden Befehlen:

  • New-MsolGroup -Displayname „Gruppenersteller“ -Description „This group is intended for power users, who are able to create Groups“
  • Get-MsolGroup -SearchString Gruppenersteller
    -> Screenshot
  • $setting = $template.CreateSettingObject()
    -> Screenshot
  • $setting[„EnableGroupCreation“] = „$false“
  • $setting[„GroupCreationAllowedGroupId“] = „ID“
  • New-MsolSettings -SettingObject $setting
    -> Screenshot

3. Gruppenersteller einschränken durch Anpassen einer Gruppenvorlage:

Wir konzentrieren uns nun aber auf das Anpassen einer bereits existierenden Vorlage mit entsprechenden Standardwerten. Wie im obigen Beispiel, erstellen oder suchen wir die entsprechenden AD-Gruppe, die wir berechtigen wollen:

  • New-MsolGroup -Displayname „Gruppenersteller“ -Description „This group is intended for power users, who are able to create Groups“
  • Get-MsolGroup -SearchString Gruppenersteller

Damit ist der einfachste Schritt erledigt – weiter zum nächsten.

Wir müssen nun die ID der existierenden Vorlage identifizieren und wollen uns die darin enthaltenen Werte auslesen lassen:

  • $setting = Get-MsolSettings -SettingId „ObjectId“
  • $setting.Values
    O365 Groups Governance Get-MsolSettings

Wir sehen also, dass das Erstellen der Gruppen generell angeschaltet ist (EnableGroupCreation = True) und noch keine explizite Gruppe zum Erstellen zugewiesen wurde (kein Wert bei GroupCreationAllowedGroupId). Dies wollen wir nun ändern. Dafür hilft uns die GetSettingsValue – Methode, über die wir dann die Werte definieren. Anschließend schreiben wir diese Werte in das existierende SettingsObject.

  • $value = $setting.GetSettingsValue()
  • $value[„GroupCreationAllowedGroupId“] = „ID“
  • $value[„EnableGroupCreation“] = „$false“
  • Set-MsolSettings -SettingId „ID“ -SettingsValue $value

Anschließend vergewissern wir uns noch einmal, dass die Einstellungen auch erfolgreich geschrieben wurden:

$setting.Values

Im Screenshot ist dies nun schön zu sehen, dass wir erfolgreich die Standardwerte geändert haben. Das Erstellen von neuen Gruppen ist jetzt das Privileg der Mitglieder der entsprechenden AD-Gruppe.
O365 Groups Governance Gruppenersteller einschränken

Es ist noch interessant zu erwähnen, dass ich diese Vorlage auch nur explizit den Office Web Apps zuweisen kann. Das heißt, dass ich vielleicht grundsätzlich das Erstellen erlauben möchte, aber nicht über die Mail und People Ansicht in den Office Web Apps. Neben der Option für Administratoren im O365 Admin Center, können so dann nur noch Gruppen im Planner und bei einer neuen SharePoint Site Collection angelegt werden. Aus meiner Sicht ist dies auch schon mal ein guter Start in mehr Struktur und Übersicht bei den O365 Groups.

4. Klassifizierung:

Aus dem obigen Screenshot der verfügbaren Einstellungen für eine Gruppenvorlage war schon zu sehen, dass es dort auch eine „ClassificationList“ gibt. Hier kann ich genauso vorgehen, wie beim Einschränken der Gruppenersteller und mit Komma getrennte Schlüsselwörter definieren, die dann an eine neu erstellte Gruppe angehängt werden.

  • $value[„ClassificationList“] = „Public,Internal use – non confidential,Confidential,Secret,Top Secret“

Damit kann ich leichter eine Übersicht von Gruppen nach bestimmten Kriterien erstellen, z.B. Sensitivität oder Zweck.

Wie in Teil 1 bereits erwähnt, stehen diese Werte allerdings nur beim Erstellen über SharePoint zur Verfügung und werden sonst leider nicht hinzugefügt!

5. Namenskonventionen:

Für die Namenskonventionen sehen wir auch die entsprechende Eigenschaft im Screenshot: „PrefixSuffixNamingRequirement“. Leider kann man dies ausnahmsweise nicht über PowerShell, sondern nur über das User Interface im Exchange Online Administration Center konfigurieren.

Dort navigieren wir zu den Empfängern und weiter auf Groups. Mit Klick auf „…“ öffnet sich das Kontextmenü, aus dem wir „Configure group naming policy“ auswählen.
O365 Groups Governance Namenskonvention

Hier können wir nun verschiedene Freitext-Werte vergeben sowie Attribute aus dem Benutzerkonto des Erstellers auslesen und eintragen lassen.
O365 Groups Governance Namenskonvention definieren

Am unteren Ende der Ansicht würd dann eine Vorschau angezeigt, wie ein zukünftiger Gruppenname aussehen wird.
O365 Groups Governance Namenskonvention

Beim Anlegen einer neuen Gruppe in der Mail und People Ansicht wird der resultierende Name auch gleich angezeigt, damit der Ersteller gleich weiß, wie seine Gruppe und die dazugehörige URL heißen wird.
O365 Groups Governance Namenskonvention Vorschau

Aber auch hier sei Achtung geboten, da die Namenskonventionen nicht auf Gruppen aus Planner oder SharePoint angewendet werden. Es gibt also schöne Ansätze, jedoch wirkt es, dass bei Microsoft nicht zu Ende gedacht wurde.

Schön finde ich auch die Möglichkeit, dass bestimmte Wörter nicht verwendet werden können. Dies kann auch sehr einfach konfiguriert werden.
O365 Groups Governance Namenskonvention verbotene Wörter

6. Berechtigungen Einschränken:

Zurück zu PowerShell – wie bereits in Teil 1 erwähnt, gibt es ein paar Standardwerte, mit denen wir Berechtigungen auf Gruppen einschränken können. Das Konfigurieren dieser Eigenschaften funktioniert analog zur Klassifizierungsliste oder dem Einschränken der Gruppenerstellung. Zum Beispiel:

  • $value[„AllowGuestToAccessGroups“] = „$false“
  • $value[„AllowToAddGuests“] = „$false“
  • $value[„UsageGuidelinesUrl“] = „https://domain.sharepoint.com/sites/policies/Guideline.aspx“

Zusätzlich können und sollten wir die Richtlinie zum Teilen einer bestehenden Groups Site Collection weiter anpassen, da standardmäßig folgende Richtlinie hinterlegt ist: Freigabe nur für die externen Benutzer erlauben, die im Verzeichnis Ihrer Organisation bereits vorhanden sind.

Ein SharePoint Online PowerShell Befehl hilft uns, dies nachträglich anzupassen. (Hinweis: das SharePoint Online PowerShell Modul muss dazu in die Online PowerShell Konsole geladen werden.)

Set-SPOSite -Identity https://domain.sharepoint.com/sites/site1 -SharingCapability -ExternalUserSharingOnly

Dies bedeutet zum Beispiel, dass nur Externe per Email eingeladen werden können, aber kein Gäste-Link erzeugt werden kann. Weiterhin kann ich das Teilen komplett für Externe abschalten und auch erlaubte und geblockte Domains referenzieren. Weitere Informationen findet ihr dazu in der Referenz zum Set-SPO Befehl:
https://technet.microsoft.com/de-de/library/fp161394.aspx

Außerdem können die Nutzerberechtigungen der Group Site Collection angepasst werden, also ganz normal, wie man SharePoint Berechtigungen verwaltet. Dies ist aber eher nur ein Workaround, weil man diese leider nicht in einer Vorlage mit nativen Mitteln festlegen kann. Auch hier gibt es Drittanbieter am Markt, die dafür einen Mehrwert liefern können.

7. Speicherplatz beschränken:

Wenn wir nun schon in der SharePoint Online PowerShell Administration sind, dann machen wir mit dem Speicherplatz gleich weiter. Wenn das manuelle Storage Modell ausgewählt ist (und nicht der Pooled Storage), können wir Quotas nachträglich für die erstellten Group Site Collections definieren.

Set-SPOSite -Identity https://domain.sharepoint.com/sites/Group1 -StorageQuota 3000 -StorageQuotaWarningLevel 2000

Mit diesem Befehl weisen wir beispielsweise der Group Site Collection /sites/Group1 ein Quota von 3000 MB zu und eine Warnung wird bereits bei Erreichen von 2000 MB an den primären Site Collection Administrator geschickt.

 

Natürlich wäre es schöner, wenn wir alles in einer Gruppen-Vorlage definieren könnten oder gar mehrere Vorlagen zur Auswahl stellen können, aber da dies leider aktuell mit nativen Mitteln noch nicht möglich ist, sollten wir zumindest die hier beschriebenen Möglichkeiten nutzen, um Unternehmensrichtlinien auch auf die Office 365 Groups anzuwenden.

Wenn euch diese Funktionen nicht weit genug gehen, dann kann ich Drittanbieter im Markt empfehlen, die neben dem kontrollierten Anlegen von Gruppen auch gleich Backup und Lifecycle Funktionen anbieten. Mit solchen Möglichkeiten kann ich dann wirklich sorgenfrei auch produktiv mit Gruppen arbeiten.

Happy „SharePointing“!

 

Weitere Quellen:

 

FileShare Migration nach O365

9. Türchen

Nachdem wir gestern mit ein paar Tricks unseren FileShare vorbereitet haben oder zumindest die Daten sortiert haben, die wir migrieren möchten, steht heute die wirkliche Migration ins Haus. Wir wollen dabei nicht kleckern, sondern klotzen. Damit meine ich nicht, dass wir nicht lange warten wollen, um per CSOM langsam Daten hochzuladen oder eine Festplatte verschicken wollen, wofür es auch einige Limitationen gibt. Stattdessen wollen wir die – mittlerweile nicht mehr – neue High Speed Migration (HSM) API nutzen und Daten direkt über einen Azure Storage in eine SharePoint Online Bibliothek migrieren.

Dazu müssen wir aber folgendes beachten:

  • Die Pfadlängen im Ziel dürfen 255 Zeichen nicht überschreiten. Dies ist eine SharePoint Limitation, die wir im FileShare nicht kennen. Achtet daher darauf, dass eure Ordnerstruktur nicht zu tief ist, um dieses Limit nicht zu erreichen.
  • Sonderzeichen wie “ ? < > # % / \ werden in SharePoint nicht unterstützt
  • Dateien aus dem FileShare, die gerade von einem anderen Programm verwendet werden, sind gesperrt und daher auch nicht für den Migrationsprozess zugänglich.

Um nun loslegen zu können, müssen wir (neben dem Ziel-Tenant und einer Quellumgebung mit Daten) noch folgenden Dinge vorbereiten:

  1. Azure Verbindungs-Assistent
  2. Online PowerShell Module – Beides aus dem O365Adventskalender Türchen 6
  3. Azure Storage (Erstellung siehe unten)

Ok, dann starten wir nun in sechs Schritten.

1. Azure Storage erstellen

Diesen Storage brauchen wir, um das Migrationspaket in der Microsoft Cloud ablegen zu können. Ein komplett direktes Befeuern unseres SharePoints ist nämlich leider doch nicht möglich. Als Hinweis, der Storage muss aber nicht unter dem gleichen Tenant aufgehängt werden. Der Storage kann ganz woanders liegen – und auch unter einem anderen Konto laufen – als der Ziel SharePoint-Tenant. In unserem Test Tenant können wir uns auch einen Test Storage einfach konfigurieren.

  1. Im Azure Portal zu Speicher navigieren und ein neues Speicherkonto anlegen
    02a-fs-migration
    01a-fs-migration
  2. Anschließend werden wir gebeten, die Art des Speichers auszuwählen – in unserem Falle ein Testkonto – und unsere Identität per Telefonnummer und Kreditkarte zu überprüfen. Keine Sorge, es fallen wirklich keine Gebühren an, wenn man nicht explizit einem kostenpflichtigen Abo zustimmt.
    01-fs-migration 02-fs-migration
  3. Nun vergeben wir unserem Speicher einen Namen, der nur Kleinbuchstaben und Ziffern enthalten darf. Als Storage Replikation empfehle ich den Lokal Redundanten Speicher (LRS), da dieser einfach der günstigste Storage ist für 2,02 je 100 GB (aktuell) und für unsere (Test-) Migration völlig ausreichend ist. Die Ressourcengruppe, in der wir unseren Storage einordnen, muss auch noch einen Namen bekommen und die Region, die wir auswählen, sollte aus persönlicher Empfehlung immer nahe zu unserem Upload-Ort sein, denn die Verbindung der Speicher und Tenant untereinander ist von Microsoft extrem gut verkabelt. Also von welcher Azure Storage Region wir die Daten in SharePoint pumpen hat kaum einen Einfluss, aber natürlich unsere eigene Upload-Leitung zu einer entsprechenden Azure Storage Location schon.
    03-fs-migrationDie Bereitstellung des Speichers dauert nur wenige Sekunden bis Minuten. Danach finden wir unseren Storage Namen sowie den Storagy Key unter der Kategorie Zugriffsschlüssel. (für manche Prozesse ist auch die Application ID nötig, aber nicht für unsere Migration.)
    04-fs-migration
    05-fs-migration

 

2. Verbindungsaufbau zu O365

Zur Erinnerung, bevor wir mit PowerShell loslegen können, müssen wir zunächst der Verbindungsaufbau zu O365 aufbauen und die Module in der Azure PowerShell Konsole laden, die ihr als Administrator geöffnet habt:

  • $Creds = Get-Credentials
  • Import-Module Microsoft.Online.SharePoint.PowerShell -ErrorAction SilentlyContinue
  • Connect-SPOService -Credential $Creds -Url https://yourdomain-admin.sharepoint.com

3. Paket erstellen 

Nun haben wir alle Vorbereitungen getroffen, also erstellen wir uns nun ein Migrationspaket. Dabei geben wir mit, welche Dateien von dem FileShare inkludiert werden sollen. Daher ist die gestrige Vorbereitung so hilfreich gewesen. Ich habe versucht, in der Eingabeaufforderung die Variablen so eindeutig wie möglich zu formulieren, daher kommentiere ich es nicht weiter aus. Wenn ihr Fragen habt, einfach fragen! 🙂

Einen Hinweis noch: die Zielpfade müssen schon existieren, da im Konvertierungsprozess bereits eine Verbindung zum Ziel aufgebaut wird, um entsprechend die Daten zu mappen. Die PowerShell Befehle verwenden zudem die internen SharePoint-Namen. Also in Office 365 ist die „Documents“ Bibliothek intern immer noch die „Shared Documents“ MIT Leerzeichen, aber ohne „%20“. Darauf müsst ihr achten.

  • $QuellPfad =   „\\Server\C`$\FileShare\O365Migration“
  • $QuellPaketPfad = „\\Server\C`$\FileShare\O365Migration\Paket“
  • $ZielPaketPfad = „\\Server\C`$\FileShare\O365Migration\Paket-Output“
  • $Zielweburl = „https://yourdomain.sharepoint.com/sites/yoursite“
  • $Zielbibliothek = „FileShare“
  • $ZielOrdner = „OnlineMigration“ (optoinal)

 

  • New-SPOMigrationPackage -SourceFilesPath $QuellPfad -OutputPackagePath $QuellPaketpfad -TargetWebUrl $Zielweburl -TargetDocumentLibraryPath $Zielbibliothek -TargetDocumentLibrarySubFolderPath $ZielOrdner –NoAzureADLookup

 

4. Paket konvertieren

Nachdem wir das Paket erstellt haben, müssen wir es in ein von SharePoint Online verständliches Format konvertieren. Dafür nutzen wir den ConvertTo-SPOMigrationTargetedPackage Befehl. Mit diesem Verbinden wir uns auch schon auf die zukünftige SharePoint Online Bibliothek, damit schon die Mappings auf die Zielbibliothek und Ordner vorgenommen werden können. Und ich kann sogar noch mehr mappen – nämlich Benutzer! Denn On-Premises Benutzer haben nicht immer genau die gleiche ID in O365. Ist das der Fall, macht also ein Mapping Sinn. Dazu müssen wir den -NoAzureADLookup Switch weg lassen, aber ersetzen ihn durch den -UserMappingFile Switch. Damit können wir eine CSV Datei referenzieren, in der für jeden Nutzer eine OnPremSID, UPN sowie eine Wahr/Falsch Angabe zur Gruppenzugehörigkeit angegeben wird. Was diese genau aussagen, seht ihr in der Tabelle:

OnPremSID UPN isGroup
Die Active Directory-SID des lokalen Benutzers oder der lokalen Gruppe (Windows/AD-Authentifizierung an der Quelle vorausgesetzt), die für den Nachschlag des Eintrags in der Datei UserGroup.XML verwendet wird. Der UPN (z. B. E-Mail-Adresse) des Kontos, der im Ziel verwendet werden soll. Handelt es sich bei dem Konto um eine Benutzer- oder Domänengruppe? (Gebt TRUE oder FALSE ein)

So eine CSV muss schon vor der Migration für alle Benutzer erzeugt worden sein, die vermutlich im Migrationspaket enthalten sein werden. Solltet ihr jedoch kein User Mapping brauchen, dann reicht nun also zum Konvertieren dieser Befehl:

  • ConvertTo-SPOMigrationTargetedPackage -SourceFilesPath $QuellPfad -SourcePackagePath $QuellPaketPfad -OutputPackagePath $ZielPaketPfad -TargetWebUrl $Zielweburl -TargetDocumentLibraryPath $Zielbibliothek -TargetDocumentLibrarySubFolderPath $ZielOrdner -Credentials $Creds

 

5. Hochladen

Nun laden wir das neue Paket, das im Ordner kaum anders aussieht, als das erste Pakte, auf unseren Azure Storage hoch. Die entsprechenden Namen für unsere Pakete und Container dürfen übrigens auch nur Kleinbuchstaben und keine Sonderzeichen enthalten. Der Payload stellt dann die eigentlichen Daten dar und der PaketContainer das Manifest und Einstellungen für die Migration. Zusätzlich brauchen wir in diesem Schritt das Speicherkonto und den Schlüssel.

  • $PayloadContainer = „migrationayload“
  • $PaketContainer = „paketcontainer“
  • $AzureWarteschleife = „fileshareupload“
  • $AzureKontoName = „robtheninja“
  • $AzureStorageKey =“hierdeinazurekey==“

 

  • $Upload = Set-SPOMigrationPackageAzureSource –SourceFilesPath $QuellPfad –SourcepackagePath $ZielPaketPfad –FileContainerName $PayloadContainer –PackageContainerName $PaketContainer –AzureQueueName $AzureWarteschleife –AccountName $AzureKontoName -AccountKey $AzureStorageKey

Wer möchte, und wem der „Ladebalken“ in der PowerShell Konsole zu langweilig ist, der kann diesen Vorgang mit einem Explorer-Fenster verfolgen. Dazu gibt es auf Codeplex einen sogenannte Azure Storage Explorer, in dem das Ganze dann folgendermaßen aussieht.

08-fs-migration

Dieser Explorer ist auch sonst noch sehr nützlich, wenn man seinen Speicher auch noch für anderen Dinge verwendet, als nur zum Migrationsupload. Also schaut ihn euch wirklich einmal an.

 

6. Migration Starten

Das sieht ja nun schon mal gar nicht schlecht aus. Also müssen wir jetzt nur noch die Migration starten. Dies geht mit folgendem Befehl:

Submit-SPOMigrationJob –TargetwebUrl $Zielweburl –MigrationPackageAzureLocations $Upload –Credentials $Creds

Auch hier können wir mit dem Azure Storage Explorer den Migrationsfortschritt beobachten und schauen, welche Events in der Warteschleife hinzukommen.

08a-fs-migration

Optional können wir auch:

  1. den Status der Migration direkt in der Konsole abfragen mit
    Get-SPOMigrationJobStatus -TargetWebUrl https://yourdomain.sharepoint.com/sites/site
  2. den Migrationsjob am Ende der Migration löschen mit
    Remove-SPOMigrationJob -JobId GUID -TargetWebUrl https://yourdomain.sharepoint.com/sites/site
    Weitere Informationen zum Remove-SPOMigrationJob gibt es hier: https://technet.microsoft.com/en-us/library/mt143607.aspx

Mit diesen beiden Befehlen könnt ihr also direkt den Status abfragen und sicher den Prozess beenden. Mit dem Azure Storage Explorer seht ihr es auch, wenn in der Warteschleife (hier: Queue „fileshareupload“) ein Event „End“ auftaucht. Danach wird auch eine Log-Datei zum abgeschlossenen Migrationsjob in den Payload-Ordner (hier: „migrationpayload“) gelegt.

Im Ziel kommt dann in der Tat alles so an, wie es auf dem FileShare war, sogar mit Ordnerstruktur und den originalen Metadaten, wie Ersteller oder Erstellungsdatum (siehe Screenshot).

10-fs-migration

Sicherlich ist eine Migration mit Hilfe des Microsoft FastTrack noch einfacher, auch wenn selbst dies keine „White Gloves“ Migration ist. Und generell sind 82% aller Migrationen keine einfachen Migrationen. Aber für kleine Firmen und einfache FileShares ist dieser Ansatz mit der HSM API kein komplizierter. Ich kann nur empfehlen, einfach mal ausprobieren, mir hat es wirklich Spaß gemacht, wie schnell und einfach hier alles funktionierte. Ich drücke die Daumen, dass dies auch bei euch der Fall ist.

Weitere Informationen zum Datendurchsatz und möglicher Drosselung der API erfahrt ihr hier:
https://support.office.com/de-de/article/Migrationsgeschwindigkeit-von-SharePoint-Online-und-OneDrive-for-Business-21cfb6a0-fa4c-44c6-9a39-0f45e85e371f?ui=de-DE&rs=de-DE&ad=DE&fromAR=1

Sollte euch das dennoch zu stressig sein oder ihr habt einfach nicht die Zeit und Ressourcen, so ein Projekt durchzuführen, dann gibt es auch sehr gute 3rd Party Lösungen am Markt, die ebenfalls die HSM API nutzen, aber auch direkt ohne Storage mit Multi-Threading die Daten hochladen können – und das Ganze nicht nur von FileShares, sondern auch Notes, LiveLink, Documentum, etc. Immer optimistisch denken, für jedes Problem, gibt es eine Lösung. 🙂

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

SharePoint Online PowerShell

7. Türchen

Mit dem Herstellen einer PowerShell-Verbindung zu unserem Online Tenant, was logischerweise nicht so trivial ist, wie bei unseren On-Premises Produkten, haben wir gestern den allgemeinen Teil zu Office 365 abgeschlossen und widmen uns in den nächsten Tagen den einzelnen Technologien und starten heute mit SharePoint.

Sollten wir unsere PowerShell Konsole noch offen haben, können wir nun direkt loslegen mit unseren Befehlen, um Seiten, Listen und Bibliotheken anzulegen, Eigenschaften auszulesen und anzupassen. Also im Prinzip Copy/Paste der uns bekannten Befehle aus On-Premises.

Halt Stopp!

Leider ist dies nicht so und als SharePoint Infrastruktur Spezialist bin ich wirklich enttäuscht, was für IT Pros in der SharePoint Online PowerShell Konsole zur Verfügung steht.

Aktuell gibt es ganze 33 Befehle. (https://technet.microsoft.com/de-de/library/fp161364.aspx). Im Vergleich dazu gibt es in der SharePoint 2013 Version 733 Befehle. In der 2016er Version kommen sogar noch ein paar dazu. Eine zentrale und automatisierte Verwaltung meines SharePoint Online ist daher nur sehr eingeschränkt über das UI oder noch weniger per PowerShell möglich. Ganz sicher wird sich da etwas tun, aber derzeit bleibt uns nur Drittanbieter-Software, die direkt über die API eine große Vielzahl an Funktionen zur Verfügung stellt.

Eine Alternative ist es, selbst Code zu schreiben, der über die API die gewünschten Aktionen ausführt. Ein schönes Beispiel, um Listenobjekten auslesen oder erstellen zu können, findet ihr auf dieser Seite:

http://www.c-sharpcorner.com/article/list-item-operations-using-csom-with-powershell-for-sharepoi

Aktuell ist nicht ganz sicher, in welche Richtung Microsoft gehen wird. Ohne Frage wird es weitere PowerShell Befehle für SharePoint geben, aber auf der anderen Seite gibt es nun auch Microsoft Flow und PowerApps. Mit ihnen können Administratoren ohne Entwicklerkenntnisse auch ganz einfach Funktionen zur Verfügung stellen, welche sonst On-Premises nur über PowerShell möglich waren.

Microsoft hat auf der ESPC 2016 erneut bestätigt, dass ein großer Fokus in Zukunft auf Entwickler für SharePoint gelegt wird. Auf der anderen Seite ermöglichen es Programme wie Flow, PowerApps und auch PowerBI engagierten Nutzern, sogenannten Power-Usern, ohne großen Aufwand auch komplexe angepasste Funktionen für ihr Unternehmen bereit zu stellen. Man kann fast glauben, dass der IT Pro, dessen beliebtes „Spielzeug“ PowerShell ist, in Zukunft fast nicht mehr für SharePoint Online gebraucht wird. Eine Entwicklung hin zu Programmierern oder zu Power User könnte uns bevor stehen.

Beunruhigen sollte uns dies jedoch nicht. Zu früh ist aktuell noch die Entwicklung und natürlich auch zu gewagt meine These. Also durchatmen und erst einmal einen Spekulatius verputzen. 😉

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

O365 PowerShell Verbindung

6. Türchen

Einen fröhlichen Nikolausi wünsche ich allen!!! 🙂

Heute schauen wir uns an, wie wir uns denn mit Office 365 per PowerShell verbinden können, denn O365 ist ja nicht in unserem Datencenter. Daher kann ich nicht mal eben die PowerShell Konsole öffnen und direkt mit meinen Befehlen loslegen. Aber warum möchte ich das überhaupt? Der Grund ist, dass die PowerShell Schnittstellen sich langsamer ändern, als das User Interface (UI) des O365 Administrationsportal. Schon allein die gestern beschriebene Navigation zur Verwaltung von Office ProPlus sah vor etwa einem Jahr noch völlig anders aus und wir werden sehen, bis wann auch dies erneut überarbeitet wird.

Mit PowerShell können wir aber auch Konfigurationen anpassen, die über das UI gar nicht möglich sind. Aus diesen Gründen ist die Verwaltung von Office 365 über PowerShell empfohlen. Also wie legen wir nun los?

Um uns auf unsere PowerShell-Reise begeben zu können, müssen wir uns zunächst den Microsoft Online Services-Anmelde-Assistent und drei PowerShell Module runter laden. Die Module sollten auch in dieser Reihenfolge installiert werden!

  1. Service-Anmelde-Assistent:
    http://go.microsoft.com/fwlink/p/?LinkId=286152
  2. Windows Azure Active Directory-Modul (64-bit):
    http://go.microsoft.com/fwlink/p/?linkid=236297
  3. SharePoint-Modul:
    http://go.microsoft.com/fwlink/p/?LinkId=255251
  4. Skype-Modul:
    http://go.microsoft.com/fwlink/p/?LinkId=532439

Je Installation muss man lediglich den Vertragsbestimmungen von Microsoft zustimmen oder maximal noch einen Installationspfad mit angeben. Ansonsten sollte dieser Part schnell über die Bühne gehen.

Bevor wir dann mit PowerShell loslegen können, müssen wir die Konsole als Administrator ausführen und die ExecutionPolicy auf mindestens „RemoteSigned“ setzen, da standardmäßig „Restricted“ eingestellt ist. Dies ist nötig, damit wir unsere Module und die darin enthaltenen Befehle ausführen können. Weitere Details zur ExecutionPolicy findet ihr hier:
https://technet.microsoft.com/de-de/library/ee176961.aspx

05a-ps-console

Anschließend lassen wir die Zugangsdaten unseres Tenant-Administrators in eine Variable schreiben, weil wir diese zum Verbinden auf die verschiedenen Office 365 Produkte benötigen.

$creds = Get-Credential
05-login_neu

Anschließend importieren wir die Befehle der Online Services und stellen mit den Zugangsdaten eine Verbindung zum Portal her.

  • Import-Module MsOnline
  • Connect-MsolService -Credential $creds

Das wäre es eigentlich schon. Aber natürlich wollen wir auch mit den entsprechenden Produkten arbeiten, daher machen wir nun mit dem Import und Verbinden der SharePoint, Skype und Exchange Module weiter.

SharePoint:

  • Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking
  • Connect-SPOService -Url https://yourdomain-admin.sharepoint.com -Credential $creds

Skype for Business

  • Import-Module SkypeOnlineConnector
  • $S4BSession = New-CsOnlineSession -Credential $creds
  • Import-PSSession $S4BSession

Exchange:

  • $ESession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri „https://outlook.office365.com/powershell-liveid/“ -Credential $creds -Authentication „Basic“ -AllowRedirection
  • Import-PSSession $ESession -DisableNameChecking

06-ausfuehren

Im Prinzip ist es das schon gewesen. Und all das passt auf eine einzige PowerShell-Konsolenseite. Es gibt also nichts, wovor man zu großen Respekt haben muss. Wir können nun mit einem einfachen Online Befehl auf unsere verwalteten Domains (Get-MsolDomain) oder existierenden SharePoint Site Collections (Get-SPOSite) einen Test starten, ob alles funktioniert hat:

07-test-neu

Hurra, ich sehe meine verwalteten Domains und meine Site Collections. Der Verbindung war also erfolgreich.

Wem ist eigentlich bei der Verbindung zu Exchange etwas aufgefallen, was man hinterfragen kann? Es geht um die Authentifizierung in „Basic“. Diese Authentifizierungsmethode überträgt den Benutzernamen und Passwort eigentlich in Klartext. Die Verbindung zu Exchange Online wird jedoch über https und damit SSL verschlüsselt vorgenommen, sodass die Zugangsdaten dennoch geschützt sind. Auch andere Methoden zur Authentifizierung wären möglich, aber dafür müssen dann auch auf Seiten Office 365 die entsprechenden Anbieter installiert und konfiguriert werden. Dies würde hier aber zu weit ins Detail führen und ist zunächst auch aufgrund der SSL Verschlüsselung nicht zwingend erforderlich. Probiert also gern sofort die Verbindung auf euren Tenant per PowerShell aus!

Bitte zum Beenden eurer Session immer folgenden Befehl (mit euren oben verwendeten Variablen) verwenden, damit alle Verbindungen sauber geschlossen werden:

  • Remove-PSSession $S4BSession ; Remove-PSSession $ESession ; Disconnect-SPOService

Weitere Details zu unseren verwendeten Befehlen findet ihr hier: https://technet.microsoft.com/de-de/library/dn568015.aspx

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

SharePoint 2016 Site Collections super schnell erstellen

Microsoft hat uns mit SharePoint 2016 eine kleine aber feine Rafinesse zur Verfügung gestellt, wenn wir Site Collections erstellen möchten. Jeder Farmadministrator, der „mal schnell“ eine Site Collection erstellen musste, kennt folgendes Szenario sicher: Nach dem Absenden der Erstellung holen wir uns erst einmal einen Kaffee, so wie wir es früher beim Start langsamer Computer gemacht haben. Denn eine Erstellung dauert ungefähr 40 (+/-) Sekunden, bis die Seite wirklich da ist.

Wenn ich nun in einem Unternehmen die Richtlinie verfolge, dass pro Projekt oder Mandant oder Kunde eine Site Collection erstellt werden muss, dann kann dies bei größeren Firmen zu sehr viel Wartezeit führen. Microsoft hat für dieses Szenario eine „Kopieren und Einfügen“ Funktion für Site Collections eingebaut. Statt 40 Sekunden braucht dieser Prozess nur noch eine Sekunde. Um diese Funktion zu nutzen, benötige ich zwei Schritte:

  1. Eine Vorlage für das „Fast-Site-Creation“ Verfahren aktivieren
    Enable-SPWebTemplateForSiteMaster -Template „STS#0“ -CompatibilityLevel 15
  2. Diese Vorlage dann als Master in einer ausgewählten Datenbank abspeichern
    $DB = Get-SPContentDatabase -site http://WebApp/sites/TeamSite
    New-SPSiteMaster -ContentDatabase $DB -Template „STS#0“

Ist dies erledigt, so sehe ich auch in meiner Zentraladministration, dass ein Site-Master als Site Collection angelegt wurde.

Als nächstes kann ich bereits mit dem richtigen PowerShell Befehl eine Site in Windeseile erstellen lassen.

New-SPSite http://WebApp/sites/Fast -Template „STS#0“ -ContentDatabase „P_SP_Content_Intranet“ -OwnerAlias „Contoso\administrator“ -CreateFromSiteMaster

 

Was müssen wir berücksichtigen?

  1. Sie sehen an dem Befehl, dass der einzige Unterschied zu einem normalen Erstellungsprozess der Switch „-CreateFromSiteMaster“ ist. Ohne diesen wird die Site nach dem Standard-Verfahren erzeugt. Auch das Erstellen über die Zentraladministartion verwendet den Standard-Prozess, sodass diese neue Funktion wirklich nur per PowerShell zur Verfügung steht.
  2. Dieser neue Prozess erstellt die Seite auf Datenbankebene. Damit ersparen wir uns einiges an „Hin und Her“ zwischen SharePoint and SQL Server, weil eben nicht das SharePoint Object Model verwendet wird. ABER, dies bedeutet gleichzeitig, dass nicht alle Features aktiviert werden können. Microsoft weist aber freundlich beim Erstellen das Site-Masters darauf hin, dass basierend auf der verwendeten Vorlage (- auch angepasste Vorlagen sind möglich -) noch bestimmte Features nachträglich aktiviert werden müssen, weil dies nicht für alle möglich ist. Mit dem Get-SPSiteMaster Befehl kann dies auch nachträglich herausgefunden werden. Dies ist interessant für Entwickler, deren Anpassungen bestimmte Features benötigen. Solche müssen somit noch explizit nach der Kopie zu einer neuen Site Collection aktiviert werden.

Fassen wir die Befehle noch einmal zusammen:

Enable-SPWebTemplateForSiteMaster Aktiviert die entsprechende Vorlage für den
Fast-Site-Creation Prozess
Disable-SPWebTemplateForSiteMaster Deaktiviert entsprechende Site Collection
Get-SPWebTemplatesEnabledForSiteMaster Zeigt alle Vorlagen an, die für den
Fast-Site-Creation Prozess aktiviert wurden
Get-SPSiteMaster Zeigt einen entsprechenden Site-Master an
(um z.B. die zu aktivierenden features erneut zu identifizieren)
New-SPSiteMaster Erstellt einen neuen Site-Master
Remove-SPSiteMaster Löscht einen Site-Master

Habe Sie beispielsweise ein „Self-Service-Portal“ auf Basis von PowerShell zur Provisionierung von Site Collections, dann empfehle ich dieses Feature zu nutzen, weil die Endbenutzer so noch schneller ihre angeforderte Seite zur Verfügung gestellt bekommen.

Also viel Spaß beim „SharePointen“!

SharePoint BLOB Management – Shredded Storage

SharePoint Adventskalender – 20. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

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

Seit Microsoft den Shredded Storage für SharePoint 2013 herausgegeben hat, kursieren verschiedene Mythen und Gerüchte über Best Practices und die kombinierte Anwendung mit dem Remote BLOB Storage (RBS) bei IT-Administratoren. So habe ich bei Kunden bereits gehört, dass RBS als Synonym für Shredded Storage verwendet wurde. Außerdem hört man, dass aufgrund der kleinen Datei-Chunks, der RBS-Grenzwert nie berührt wird, oder aber, dass Shredded Storage den RBS sogar obsolet macht.

Um mit diesen Mythen aufzuräumen und Best Practice Empfehlungen geben zu können, besonders in der Kombination des Shredded Storage mit RBS, konzentrieren wir uns heute zunächst auf die Spezialitäten des Shredded Storage.

Abstrakt betrachtet macht der Shredded Storage Algorithmus folgendes:


Technisch sieht dies aber natürlich etwas anders aus. Einfach gesprochen ist der Shredded Storage die Aufteilung einer Datei in viele kleine Teile, sogenannte Chunks. Die „FileWriteChunkSize“ ist dabei der Wert, der angibt, wie groß die Fragmente beim Schreiben in den SQL sein dürfen. Es sind jedoch nicht alle Teile gleich groß, denn z.B. der Header und Footer der Datei kann eine andere Größe haben. Diese Architektur lässt somit auch erahnen, dass eine Datei im Shredded Storage Konzept zunächst etwas größer ist, als im alten Format, da mehr Informationen gespeichert werden müssen, um die einzelnen Chunks am Ende wieder zusammensetzen zu können. Sobald jedoch erste Änderungen einer Datei mit Versionierung gespeichert werden, wird dieser anfängliche Mehrbedarf an Speicher wieder egalisiert.

Der Algorithmus macht auch keine Unterschiede mehr zwischen Office Dokumenten, Bildern oder anderen Dateitypen. Er versucht grundsätzlich jedes Dokument in Chunks zu zerlegen. Je nach Dateityp und Komplexität der Datei kann dies besser oder schlechter funktionieren. Zum Beispiel: Bei einem meiner Kunden hat eine neue Version einer PowerPoint-Datei fast die gleiche Größe gehabt, wie die Erstversion. Normalerweise sollte mit dem Shredded Storage aber nur das Delta, also beispielsweise die kleine Änderung im Titel, neu gespeichert werden und nicht das gesamte Dokument. Offensichtlich konnte der Algorithmus die Datei aber nicht in kleinere Chunks zerlegen.

Ziele des Shredded Storage:
Während das Hauptziel des gestern vorgestellten RBS die Auslagerung von großen Dateien ist, so verfolgte Microsoft bei der Entwicklung des Shredded Storage folgende vier Ziele:

  1. Bandbreitenoptimierung
    • nur noch Teile einer gesamten Datei müssen gesendet werden
    • dies ermöglicht und verbessert auch das Co-Authoring bei Office-Dokumenten
  2. I/Ops optimieren
    • durch kleinere Datenpakete werden die I/O Muster geglättet
    • es wird realisiert, dass Schreibkosten proportional zur Größe der Änderungen sind
    • es müssen weniger Änderungen an den SQL gesendet werden (nur Delta, nicht gesamte Datei). Dies verkleinert die Transaction Logs und erhöht damit auch die Backup-Performanc
  3. Storage reduzieren
    • es werden nur noch die Änderungen gespeichert, nicht erneut die gesamte Datei
  4. Sicherheit
    • es ist nun schwieriger eine gesamte Datei mit einem PowerShell-Befehl auszulesen
    • mit aktivierter Verschlüsselung kann jedes Datei-Chunk einzelnd verschlüsselt werden

Best Practice:
Basierend auf mehreren Tests mit unterschiedlichen Dateigrößen hat sich ergeben, dass eine FileWriteChunkSize von 1250 KB die beste Performance für Up- und Downlaods erzielt. Je nach Umgebung sowie Art und Größe der Daten, kann auch ein etwas höherer Wert Sinn machen. Als Beispiel, beim Microsoft Cloud-Storage OneDrive werden 2 MB verwendet. Allerdings sollte der Wert nicht größer als 4 MB sein. Warum? Der Hintergrund ist, dass viele System-Operationen Änderung in 4 MB Paketen verarbeiten. Kommt nun ein größeres Datenpaket, so wird dies nur in 4 MB Schritten gelesen – also in 4 MB Pakete „zerschnitten“. Das verursacht einen signifikanten Anstieg der I/Ops. Stattdessen sind zuvür „gekürzte“ Fragmente durch den Shredded Storage deutlich einfach zu verarbeiten.

„For Your Information:“

  • Zusätzlich zu der FileWriteChunkSize gab es auch noch die FileReadChunkSize. Diese Variable sollte zusätzlich die Größe der Pakete definieren, in denen die Daten ausgelesen werden. Da dies aber keine entscheidenen Vorteile brachte, wurde diese Einstellung wieder abgekündigt und man verwendet nur noch die FileReadChunkSize.
  • In SharePoint 2016 wird der Shredded Storage nicht mehr mit dem Cobalt, sondern mit dem BITS (Background Intelligent Transfer Service) Protokoll arbeiten. Damit sind zusätzliche Vorteile möglich, wie z.B. das Unterbrechen und Fortsetzen von Übertragungen (für mehr Stabilität) oder die Verwendung von ungenutzten Netzwerkresourcen zur Übertragung (um nicht andere Netzwerkaktivitäten negativ zu beeinflussen)

Zur Vollständigkeit hier noch die PowerShell Befehle, um den Shredded Storage zu konfigurieren. Achten Sie darauf, dass der Wert nur für die gesmate Farm konfiguriert werden kann, auch wenn der allgemeine PS-Ansatz etwas anderes vermuten lässt. Dies liegt daran, dass der Shredded Storage ein Web Service ist. Sollten Sie also den Shredded Storage im „gewöhnlich“ Fall mit einer bestimmten Web Application konfigurieren, behalten Sie im Hinterkopf, dass die anderen Web Applications dieses Wert auch übernehmen. Die folgenden Befehle machen diesen Sachverhalt deutlich:

Casual:
$webapp = Get-SPWebApplication http://WebAppUrl
webapp.WebService.FileWriteChunkSize =
chunk size in Bytes
$webapp.webservice.update()

Formal :
[void][System.Reflection.Assembly]::LoadWithPartialName(„Microsoft.SharePoint“)
$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$service.FileWriteChunkSize = 1280000
$service.Update()

Viel Spaß beim „SharePointen“

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

Weitere Türchen:

SharePoint Configuration Best Practices – Request Management Service

SharePoint Adventskalender – 17. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

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

Bei dem heutigen Thema schauen wir uns einen weniger bekannten Service an, der jedoch sehr interessante Funktionen für uns bereit hält. Die Rede ist vom Request Management Service. Dies ist eine Art Load Balancer hinter dem Load Balancer. Damit kann SharePoint selber bei ankommenden Anfragen entscheiden, ob wirklich der vom Load Balancer zugewiesene WFE die Anfrage bearbeitet, oder ob noch einmal zu einem anderen WFE geroutet wird.

Ein Load Blanacer, wie der F5, arbeitet für ein Netzwerk-Load-Balancing während das Request Management (RM) auf Application-Eben die Last verteilt. Dazu können Throttling Regeln zum „bremsen“ und Routing Regeln zum priorisieren verwendet werden. Der Service ist standardmäßig ausgeschaltet, aber kann pro Web Application über PowerShell konfiguriert werden.

Funktionsweise:
Jedem Server kann über PowerShell ein statischer „Health“-Wert gesetzt werden. Zusätzlich prüft SharePoint alle 5 Sekunden die dynamische „Health“ jedes WFE Servers. Die Skala geht von 0 („am gesündesten“) bis 10. Bekommt ein Server drei mal hintereinander den Wert 10 (z.B. weniger als 20 MB RAM verfügbar), drosselt das RM die Anfragen auf diesem Server. Damit kann verhindert werden, dass ein Routing vom Load Balancer zu einem hängenden Server keine Fehlermeldung beim Endnutzer generiert. Stattdessen wird die Anfrage neu geroutet. Der Request Service fungiert praktisch als Proxy und erstellt eine neue Anfrage, die der alten zwar gleicht, jedoch zu einem neuen WFE geht.

Ablauf:

Zunächst kommt eine Abfrage vom Endnutzer oder vom Load Balancer am SharePoint an.

  1. Dieser evaluiert den Request anhand definierter Regeln. Diese können Eigenschaften (Url, UrlReferrer, UserAgent, Host, IP, HttpMethod, SoapAction, CustomHeader) oder Methoden (StartsWith, EndsWith, Equals, RegEx) überprüfen.
  2. Mögliche Server werden anhand der Regelkriterien und/oder der Server-Gesundheit identifiziert (siehe Bild unten)
  3. Nach Identifizierung des Servers wird der Request dorthin geroutet (bzw. gebremst, bei Throttling Regel).

Regeln werden innerhalb von drei Gruppen (Execution Groups 0 bis 2) zusammengefasst und entsprechend priorisiert. Diese Gruppen repräsentieren Servergruppen, zu denen geroutet werden soll.

  1. Gruppe 0 wird als erste geprüft.
  2. Gibt es keinen Match, werden die Regeln von Gruppe 1 geprüft.
  3. Gibt es ein Match, werden alle Regeln einer niedrigeren Priorität (Execution Group 2) verworfen und der Request direkt bearbeitet.

Gäbe es auch in Gruppe 2 keinen Match, dann wird der Request zu irgendeinem Server geleitet – aber nur dann, wenn ich mindestens in die letzte Gruppe auch eine Art „Catch-All“ Regel definiere, die alle nicht geregelten Anfragen abarbeitet (sollten keine weiteren „freien“ WFE außerhalb der Execution Gruppen existieren).

Vorteile:

  • Ablehnen gefährlicher Anfragen (z.B. von bestimmten Quellen)
  • Priorisieren von Anfragen basierend auf Server-Health und Regeln (z. B OneNote Verkehr immer über Server1; Search Crawler immer auf Server4; neuere Server mit mehr Resourcen können mehr Anfragen übernehmen, etc.)
  • Anfragen können „umgeschrieben“ werden mit beispielsweise sogar einem anderen Port
  • Traffic Isolierung zur Fehleranalyse (z.B. von einer bestimmten Site Collection zu einem bestimmten Server)
  • Regeln kann man auch ein Ablaufdatum mitgeben, sodass spezielle Routings automatisch enden

Nachteile:

  • Zusätzliche Last auf den WFE-Servern durch den RM Service
    Oder besser: Den RM Service auf einem dedizierten Server laufen lassen, z.B. gemeinsam mit einem Distributed Cache Service

Beispiele:

Erstellen einer Routing Regel, um alle Anfragen für Word Dokumente für Web Application http://intranet.contoso.com zum WFE „Server1“ zu leiten.

  1. Request Manager Service auf den WFEs aktivieren:
    1. Central Administration im Browser öffnen
    2. Zu Manage Services navigieren
    3. Request Management Service starten
  2. Scope der Web Application referenzieren
    • $WebApp = Get-SPWebApplication -identity http://intranet.contoso.com
  3. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  4. Erstellen eines neuen Filter-Kriteriumsmit der “Url” Eigenschaft und RegEx für alle Dokumente vom Typ DOCX
    • $Krit = New-SPRequestManagementRuleCriteria -Property Url -Value „.*\.docx“ -MatchType Regex
  5. Sollte dies die erste Regel sein, die wir erstellt haben, müssen wir auch einen Server-Pool erstellen, zu dem diese Anfragen geroutet werden sollen.
    • $Pool = Add-SPRoutingMachinePool -RequestManagementSettings $RM -Name AdventsPool -MachineTargets ($RM | Get-SPRoutingMachineInfo -Name Server1)
  6. Nun kann die Routing-Regel mit obigen Server-Pool und Filter-Kriterium angelegt werden
    • $RM | Add-SPRoutingRule -Name „DOCX Regel“ -Criteria $Krit -MachinePool $Pool
  7. Fertig und testen! (ULSViewer is your friend…)

Erstellen einer Throttling Regel, um Anfragen von OneNote auf die Web Application http://intranet.contoso.com zu bremsen, wenn der Health-Wert 8 ist.

  1. Scope der Web Application referenzieren
    • $WebApp = Get-SPWebApplication -identity http://intranet.contoso.com
  2. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  3. Hinzufügen eines neuen Kriteriums für OneNote 2010 Anfragen. Dies kann über den UserAgent im Request realisiert werden.
    • $Krit = New-SPRequestManagementRuleCriteria -Property UserAgent -Value „.*Microsoft Office OneNote 2010*“ -MatchType Regex
  4. Nun fügen wir die Throttling Regel für die Server-Health 8 hinzu.
    *Hinweis: Throttling Regeln gelten im Gegensatz zu Routing Regeln für die gesamte Farm und nicht für einzelne Server(-Pools). Daher müssen wir hier keinen Server-Pool mit angeben.

    • $RM | Add-SPThrottlingRule -Name „OneNote Throttle Rule“ -Criteria $Krit –Threshold 8

Viel Spaß beim „SharePointen“

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

Weitere Türchen:

SharePoint Configuration Best Practices – Distributed Cache Service

SharePoint Adventskalender – 16. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

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

Heute wenden wir uns dem in SharePoint 2013 neu eingeführten Distributed Cache Service zu. Dieser basiert auf dem „AppFabric Distributed Caching“ Dienst, der unter der Windows Service Konsole läuft. Er wurde dazu konzipiert, unter anderem Authentifizierungs-Tokens vom Security Token Service (STS) für den „sozialen“ Teil der MySite zu speichern. Diese zwischengespeicherten Daten sind über alle Cache-Server verteilt.

Der Vorteil dieser Technologie ist, dass Daten schnell aus dem Cache geladen werden können. Die Nachteile:

  1. Die Daten sind leider genau so alt, wie die letzte „Cache-Fütterung“. Nämlich der Timer Job mit dem Namen “User Profile Service – Feed Cache Repopulation Job” ist dafür zuständig, den Cache mit aktuellen Feeds zu füttern. Unabnhängig davon wird dieser Vorgang auch immer dann getriggert, wenn auf entsprechende Seiten zugegriffen wird. Gehe ich also auf meine MySite, so wird diese schnell aus dem Cache gerendert. Aber im Hintergrund fragt SharePoint erneut an, ob denn nicht schon aktuellere Daten für die Feeds vorhanden sind. Ist dies der Fall, wird der Cache damit versorgt und bei einem Refresh, bzw. beim nächsten Aufruf der MySite, werden dann eben diese aktualisierten Cache-Daten gerendert. Hinweis: Der Feed-Cache Timer Job läuft zusätzlich alle 5 Minuten nach Standardeinstellung.
  2. Geht ein Cache Server vom Netz, fehlen die dort gespeicherten Daten und müssen erst erneut geladen werden. Den Nachladeprozess all dieser Daten kann man folgendermaßen beschleunigen:
  • Den User Profile Service – Feed Cache Repopulation Job manuell starten oder
  • Folgende PowerShell-Befehle verwenden:
    – Clear-SPDistributedCacheItem
    – Update-SPRepopulateMicroblogLMTCache
    – Update-SPRepopulateMicroblogFeedCache

Sollte einmal bewusst geplant sein, einen solchen Server vom Netz zu nehmen, kann man auch pro-aktiv die gespeicherten Daten auf die anderen Server verteilen:

  • Stop-SPDistributedCacheServiceInstance -Graceful

Infrastrukturplanung:
Zu jeder SharePoint Farm muss auch mindestens ein Cache Host existieren, also ein Server, der den Distributed Cache Service hosted. Der – bzw. in einer größeren Farm mindestens ein – Cache Service sollte auch auf dem gleichen Server laufen, wo die User Profile Application (UPA) läuft. Andernfalls kann es vorkommen, dass sich der oben erwähnte “User Profile Service – Feed Cache Repopulation Job” nicht mit der UPA verbinden kann.

Zudem sollten Sie bei Farmen mit mehr als vier Servern explizit den Distributed Cache Service auf einem oder mehr Servern stoppen. Eine Verteilung von Cache-Daten auf zu viele verschiedene Server würde nämlich im Endeffekt die Performance negativ beeinflussen.

Weiterhin gibt es zur Planung des Distributed Cache Service folgendes zu beachten. Jeder Cache Server benötigt etwa 50% seiner Leistung für einen sogenannten RAM-Speicher-Overhead. Also administrative Aufgaben, um die tatsächlich gecachten Informationen zu verwalten. Damit wird empfohlen, Server mit maximal 16 GB RAM als Cache Server zu hosten. Prinzipiell sind auch größere Speicher möglich, aber durch den Overhead würde es bei einem Cache-Flushing so wirken, als sei der Server „eingefroren“. Dies ist nicht optimal für die „Nutzererfahrung“.

Neben den max. 16 GB RAM sollten auch etwa 2 GB für das Betriebssystem reserviert werden. Als Grundlage haben wir somit 14 GB für den Cache, wovon die eine Hälfte (7 GB) tatsächlich für den Cache und die andere Häfte für den administrativen Overhead genutzt werden soll. Somit teilen wir die gesamte benötigte Cache-Kapazität durch 7 und erhalten die Anzahl für die benötigten Cache Server.

Cache Bedarf / 7 GB = Anzahl nötiger Cache Server

Den Cache Bedarf gibt Microsoft anhand der Nutzer pro Farm mit folgender Tabelle an:

Bereitstellungsgröße Kleine Farm Mittlere Farm Große Farm
Gesamtzahl der Benutzer < 10.000 < 100.000 < 500.000
Empfohlene Cachegröße für den verteilten Cachedienst 1 GB 2,5 GB 12 GB
Gesamtspeicherzuordnung für den verteilten Cachedienst (doppelter Wert der oben empfohlenen Cachegröße, plus Reserve von 2 GB für das Betriebssystem) 2 GB 5 GB 34 GB
Empfohlene Architekturkonfiguration Dedizierter Server oder auf einem Front-End-Server Dedizierter Server Dedizierter Server
Mindestanzahl von Cachehosts pro Farm 1 1 2

Quelle: https://technet.microsoft.com/de-de/library/jj219572.aspx

Berechtigungen:
Weiterhin zu beachten ist die Berechtigung des Service Acconts, unter dem der Distributed Cache Service läuft. Ähnlich wie beim User Profile Service sind temporär erhöhte Berechtigungen (Local Admin) für das Einrichten erforderlich, um die Tokens vom STS ziehen zu können. Danach können diese Berechtigungen wieder genommen werden. Da es beispielsweise hin und wieder vorkommt, dass der Service neu gestartet werden muss oder andere administrative Eingriffe erforderlich sind, empfehle ich, die erhöhten Berechtigungen dauerhaft zu belassen. Dies widerspricht zwar dem „Least-Privilege“ Ansatz von Microsoft, erleichtert aber die Administration und Fehelerbehebung im Störungsfall.

Viel Spaß beim „SharePointen“

Hinweis:
– Die MySite wurde von Microsoft wieder abgekündigt und wird in O365 bereits durch Delve ersetzt.
– Weitere Informationen zum Distributed Cache Service finden Sie hier: https://technet.microsoft.com/de-de/library/jj219613.aspx?f=255&MSPPError=-2147217396

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

Weitere Türchen:

SharePoint Configuration Best Practices – Super User und Super Reader

SharePoint Adventskalender – 15. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

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

Besondere Funktionen erfordern besondere Einstellungen. Bei einem Feature ist das besonders wichtig. Die Rede ist von dem „SharePoint Server Publishing Infrastructure“ Feature oder auf deutsch, der „SharePoint Server-Veröffentlichungsinfrastruktur“.

Was ist an dieser Funktionalität so besonders? Die Veröffentlichungsinfrastruktur ist dazu gedacht, den SharePoint auch dafür zu nutzen, um reine Intranet- oder sogar Internetseiten zu hosten. Wichtig dabei ist, dass der Inhalt stets auf dem aktuellen Stand ist. Für Aktualisierungen werden von Dateien (Seiten) Zwischenversionen erstellt. Die Änderungen werden erst nach Veröffentlich einer neuen Hauptversion für alle Nutzer sichtbar. Dies ist natürlich auch für normale Kollaborationsszenarien denkbar, aber der Hauptfokus dieses Features liegt auf dem Veröffentlichen von Intranet- oder Internetseiten.

Das wichtigste Kriterium für eine erfolgreiche Intranetpräsenz ist ein schneller Seitenaufbau. Die Veröffentlichungsinfrastruktur nutzt dafür einen dedizierten Objekt-Cache. Wenn nun jeder Besucher durch den Aufruf einer entsprechenden Seite eine Anfrage an den SQL sendet, muss dieser auch jede einzelne bedienen. Erst bei jeder zweiten Anfrage der gleichen Seite würde der Cache tatsächlich greifen. Und dies gilt nun für jeden einzelnen Nutzer. Die Last auf dem SQL ist somit hoch und die Performance dadurch nicht optimal. Außerdem wächst der Cache schnell an, weil Dateien theoretisch doppelt und dreifach zwischengespeichert werden müssten.

Die Lösung liefern der Super User und der Super Reader Account. Bei einem Seitenaufruf werden so nur zwei Anfragen im jeweiligen Kontext der beiden Nutzer an den SQL gesendet. Der Super User („Full Control“) bekommt als Ergebnis auf diese Abfrage alle Entwürfe von Dateien, also die Zwischenversionen. Der Super Reader („Full Read“) bekommt alle veröffentlichten Versionen. Die Dateien aus beiden Abfragen landen im Cache. Für den eigentlichen Endnutzer werden dann die Berechtigungen aus den Zugriffssteuerungslisten (Acces Control List – ACL) geladen und dementsprechend nur die Informationen (aus dem Cache) gerendert und angezeigt, die er mit seinen Berechtigungen sehen darf. Der Vorteil dieses Verfahrens ist der schnelle Cache und es müssen nur die Ergebnisse für zwei Anfragen darin gespeichert werden. Dies ist also eine Performance- und Cache-Speicheroptimierung.

Nun kann es aber bei der Verwendung der Standardeinstellungen, nämlich des Systemkontos einer Website als „Portal Super User“ und des „NT Authority\Local Service“ als „Portal Super Reader“, zu Problemen kommen. Kurz: mit dem Systemkonto als „Portal Super User“ kann es zu Performance-Einbußen kommen, da hierbei manche „Entwurfsdateien“ doppelt abgefragt werden müssen. Da der „Local Service“ hingegen nicht explizit auf die jeweiligen veröffentlichten Seiten berechtigt ist, bekommt auch der Endnutzer eine Zugriffsverweigerung. Eine detailliertere Beschreibung finden Sie hier: https://technet.microsoft.com/de-de/library/ff758656.aspx)

Worauf ich aber eigentlich hinaus möchte, das ist die Authentifizierungsmethode. Microsoft änderte diese von SharePoint 2010 (Classic) zu SharePoint 2013 (Claims). Nun migrieren wir in SP2013 eine Classic-WebApplication zu Claims.

Convert-SPWebApplication -Identity „http://YourWebApp:80“ -To Claims -RetainPermissions -Force

Dies migriert auch alle berechtigten Benutzer dieser WebApplication zu Claims. Dennoch bekommen anschließend alle Nutzer – inklusive der Administratoren – einen „Zugang verweigert“ beim Zugriff auf die Seite. Besonders bei öffentlichen Seiten macht dies sehr viel „Spaß“.

Der Hintergrund ist einfach, dass bei der Classic zu Claims Migrations, auch inklusive der Benutzer, eben nicht der Super User und Super Reader mitgenommen werden. Diese verbleiben mit ihrem Classic Account und können sich daher nicht mehr authentifizieren. Sie müssen daher diese Konten erneut mit ihrer Claims-Nutzerkennung anlegen, um das Problem zu lösen. Bitte denken Sie auch daran, wenn Sie Farmlösungen oder ähnliche Programme nutzen, dass diese entsprechend mitgenommen werden müssen und sich in Zukunft über Claims authentifizieren.

Der Vollständigkeit halber hier noch die PowerShell Befehle, um die User mit Windows-Claims anzulegen:

$webapp = Get-SPWebApplication “http://WebAppURL”
$webapp.Properties[“portalsuperuseraccount”] = “i:0#.w|domain\SuperUser”
$webapp.Properties[“portalsuperreaderaccount”] = “i:0#.w|domain\SuperReader”
$webapp.Update()

Viel Spaß beim „SharePointen“!

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

Weitere Türchen: