Test-Framwork:

• SharePoint On-Premises und der entsprechenden Office Online Server Version (früher Office Web Apps)
  - Release Candidate
  - GA inklusive Mai CU
  - GA inklusive Juni CU
• SharePoint Online in O365
• Zum Verschieben der Dokumente folgende Ansätze genutzt
  - "Content and Structure" in den SharePoint Site Collection Settings
  
  - "Send To" Locations in der SharePoint Item Ribbon
  
  - Drittanbieterlösung

NEU: Durable Links

• Links sollen erhalten bleiben, selbst wenn ein Dokument umbenannt oder verschoben wird
• es wird eine ID dem Dokument hinzugefügt, an dem es in der Inhaltsdatenbank identifiziert werden soll, egal welchen Namen das Dokument hat oder welche URL davor steht
• http://intranet2016/sites/RootSite/SubSite/Shared%20Documents/Doc1.docx?d=wc6f9bf88c1a846579992030744063b1b (durable Link)
  
• Office Online Server erforderlich, mit dem der durable Link dann automatisch generiert wird

ALT: Document ID

• Zusätzliche ID von Dokumenten per Site Collection
• gedacht, um z.B. auf feste IDs per Custom Solution zu verweisen oder mit dem CQWP (Content by Query Web Part) eine Übersicht aus verschiedenen Dokumenten zusammen zu stellen
• ein Prefix der ID kann konfiguriert werden und auch erneut überschrieben werden
  
• Die ID kann auch in einer zusätzlichen Spalte angezeigt und als Link genutzt werden
• http://intranet2016/sites/RootSite/SubSite/_layouts/15/DocIdRedir.aspx?ID=ROBTHEMSGEEK-680852213-3
  
• Das Mapping hinter dem Link beruht jedoch auf dem Search Index
• Das Umbenennen und eingeschränkte Verschieben erhält die ID und den Link, ABER, die Search muss den neuen Namen oder Ablageort erneut indexieren, damit er funktioniert

NEU am ALTEN:

Vor SharePoint 2016 wurde trotz DocID der normale Link im Kontextmenü ("...") erhalten. Somit haben wir einen Link mit DocID in einer extra einzublendenen Spalte und einen normalen Link im Kontextmenü der Datei. Welchen Link nimmt nun wohl der Endanwender, um auf eine Datei zu verweisen? Richtig, den normalen. In SharePoint 2016 wurde das verbessert. Sobald man in den Site Collection Features die Document ID aktiviert, erhalten Dokumente nach durchgelaufenem Timer Service eine zusätzliche (Link-) ID. Außerdem wird der normale Link mit dem DocID-Link (DocIdRedir.aspx?ID=...) im Kontextmenü ersetzt. Damit haben wir nicht mehr zwei verschiedene Links pro Dokument, sondern nur noch den einen (besseren) Document ID Link.

-----------------------

Soviel zur Theorie. Jetzt spielen wie Myth Busters.

Und ich lege noch einen drauf. Sobald ich die Document IDs aktiviere, verschwinden die Durable Links komplett. Ehrlich gesagt ist das vielleicht auch ganz gut so, denn wir sehen oben, dass ich mit den DocID-Links einfach mehr erreichen kann.

Auf dem offiziellen und ein paar Monate alten Blog von Bill Bear (https://blogs.technet.microsoft.com/wbaer/2015/09/22/durable-links-in-sharepoint-server-2016-it-preview) werden obige Features aber noch immer uneingeschränkt so beschreiben, wie es funktionieren soll aber (noch) nicht geht. Daher auch der Vermerkt in rot bei obiger Durable Links Beschreibung. Es existieren auch unzählige andere Blogs, die von diesem tollen Feature (falsch) berichten. Denn spätestens ab dem Release Candidate wurde offensichtlich dieses Feature (sowie auch andere Funktionen siehe DLP in einem früheren Blogbeitrag [http://blogs.msdn.com/b/robert_mulsow/archive/2016/03/24/governance-und-compliance-mit-dem-neuen-sharepoint-2016-dlp-im-compliance-center.aspx]) wieder entfernt.

Grundsätzlich bin auch ich von dem Ansatz der Durable Links begeistert und unterstütze diese Idee als absolut notwenidgen Schritt in die richtige Richtung von Microsoft. Aktuell liegen Versprechen und Realität aber leider noch weit auseinander. Wir können nur hoffen, dass mit den nächsten CUs die Funktionalitäten zurück nach SharePoint 2016 kommen und auch die Durable Links wie versprochen in O365 funktionieren.

Bis dahin bleibt wachsam und viel Spaß beim "SharePointen"!

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:

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"!

Generell gibt es schon tolle Beiträge von John Peluso und Stefan Goßner über die Eigenarten des SharePoint Patchings in der Vergangenheit und wie dies SharePoint 2016 löst. Eine Kleinigkeit wird dabei jedoch ausgeklammert: Der Distributed Cache Service.

Derzeit ist der Englische Technet Artikel (nach meiner Erfahrung) korrekt:
https://technet.microsoft.com/en-us/library/mt346114(v=office.16).aspx

Darin wird gesagt, dass man acht (8) Server für die Hochverfügbarkeit in einem Zero-Downtime Patching Szenario benötigt. Allerdings wird richtigerweise darauf hingewiesen, dass es Einschränkungen mit dem Distributed Cache Service gibt

Der deutsche, russische und spanische Artikel (nach meinen persönlichen Checks) zeigen aktuell noch eine falsche Aussage. Darin wird gesagt, dass mindestens neun (9) Server erforderlich sind und der Distributed Cache Service dabei eine spezielle Rolle einnimmt mit insgesamt drei Servern, weil es einen Clusterquorum benötigt. Dies ist nicht korrekt, da der Service nicht über eine Quorum-Rolle im Cluster verwaltet wird. Stattdessen müssen die Informationen, die auf einem Cache Server gespeichert sind, für das Patching auf einen anderen Server manuell übertragen werden. Dies erfolgt per PowerShell cmdlet:

Stop-SPDistributedCacheServiceInstance -Graceful

Zusätzliche Details und weiterführende Links, wie Sie den Distributed Cache Service planen und verwalten können, habe ich bereits im letzten SharePoint Adventskalender beschrieben:
http://blogs.msdn.com/b/robert_mulsow/archive/2015/12/16/sharepoint-configuration-best-practices-distributed-cache-service.aspx

Lassen Sie sich also nicht in die Irre führen. Das Problem habe ich an Microsoft reported. Entsprechende Updates sehen Sie dann hoffentlich bald auf den Technet-Seiten. Auch ich werde diesen Artikel nach Aktualisierung anpassen.

Viel Spaß beim "SharePointen"!

Themen in diesem Beitrag:

• Zahlen und Fakten
• Aus "Seiten" wird "SharePoint"
• Simple and powerful file sharing
• Neuer Seitenerstellungsprozess
• Dokumente teilen und weitere Details
• Mobile and intelligent Intranet
• Metadatenbearbeitung (im Massenmodus)
• Spaltenerstellung
• Webparts in Teamwebseiten
• Links in der Quick-Launch
• Mobile App
• Workflows mit "Flow"
• Security, Privacy and Compliance
• Zentrale Verwaltung von Apps über O365
• Temporäre Berechtigungsvergabe
• Open and connected platform
• Eine Office Graph API für alle O365 und Yammer Anwendungen
• Client-Side Rendering mit Javascript
• On-Premises Version von SharePoint
• Feature Packs
• Migratoren

---------------------------------------------------------------------------------

Zu Beginn des Events wurden sehr beeindruckende Zahlen gezeigt, was SharePoint ausmacht und warum es aus dem Unternehmensalltag nicht mher wegzudenken ist.

Zudem zeigt Microsoft, dass Inhaltsverwaltung und Kollaboration - und damit SharePoint - der zentrale Bestandteil von Office 365 sind. Die entsprechende Kachel wird daher im Schaubild in die Mitte grückt und später zusätzlich gezeigt, dass die "Sites" Kachel in O365 nun direkt in "SharePoint" umbenannt wird, was zusätzlich den Stellenwert von Microsoft SharePoint unterstreicht.

Nun wollen wir uns den vier Kernthemen des Events und der Zukunft von SharePoint widmen:

Simple and powerful file sharing:
Das Erstellen neuer Seiten wurde neu designed. Neben dem Titel und der Beschreibung der neuen Seite, kann der Nutzer auch gleichzeitig eine O365 Gruppe erstellen lassen. Außerdem kann die Seite einer Privatsphäre-Richtlinie zugewiesen werden sowie die enthaltenen Daten hinsichtlich ihrer Sensitivität klassifiziert werden. Dies arbeitet somit gleich mit den DLP Richtlinien in O365 zusammen.

Auf der zweiten Seite des Dialogs können nun ganz einfach Nutzer als Besitzer und als Teilnehmer hinzugefügt werden. Wirklich eine einfache Art, direkt Inhalte mit einer neu erstellten Seite zu teilen.

In OneDrive oder der neuen Ansicht der Inhaltsbibliotheken wird man auf der rechten Seite weitere Details zu einem Dokument sehen können (ähnlich wie bei Detailansichten unter Windows). Darüber hinaus werden die Links angezeigt, unter welchen die Datei (oder Ordner etc.) geteilt wurden. Diese können also einfach erneut verwendet werden, möchte man die Datei mit weiteren Kollegen teilen. Mit einem Klick kann man auch einen neuen Link erzeugen, um zusätzliche Kollegen einzuladen.

Mobile and intelligent intranet:
Um gleich bei den Inhaltsbibliotheken zu bleiben, so wird obige Ansicht nicht nur zum Teilen verwendet, sondern auch Metadaten und Einstellungen werden angezeigt. Darin wird man in Zukunft noch einfacher die Daten direkt ändern können (ähnlich wie bei der QuickEdit-Ansicht). Das ganze soll sogar auch im Massenmodus möglich sein. In der Kategorieansicht, also z.B. eine Gruppierung nach Personengruppe, mit der die Inhalte geteilt wurden, kann ein Dokument von einer Kategorie in eine andere per Drag-and-Drop verschoben werden und die dahinterliegenden Metadaten (und Berechtigungen) werden automatisch angepasst. Mit einem Klick kann dann auch noch zusätzlich ein Dokument am Anfang der Bibliotheken angeheftet werden, sodass es immer oben angezeigt wird. Dies kennen wir so ähnlich aus den "Featured Links" in der SharePoint Suche.

Für die Bibliothek selber wird man bald auch noch einfacher zusätzliche Spalten hinzufügen können, ohne die Liste über die Ribbon-Bar und Bibliothekseinstellungen verlassen zu müssen. Dies ist echt eine tolle Innovation, die besonders bei neu erstelletn Listen enorm Zeit sparen wird.

Genauso einfach sollen bald auch neue Seiten angepasst werden können. Auch hier muss man nicht mehr über die Ribbon-Bar gehen, sondern kann direkt neue Web- und App-Parts in die Seite über eine einfache Benutzeroberfläche integrieren.

Ebenso einfach können die Links bearbeitet werden, was in den vorherigen und aktuellen Versionen doch wirklich noch sehr "hakelig" ist.

Bei ogiben Screenshot sehen wir auch gleichzeitig die Revolution der Teamwebseite. Das Design wird dabei auch an OneDrive und den neuen Inhaltsbibliotheken angepasst.

Ebenso verkündet wurde die Mobile-App, mit der Nutzer nun noch besser auf ihre Inhalte mobil zugreifen können. Man sieht dafür in den folgenden Screenshots schön:

wie die neue Ansicht der Team- webseiten mobil gerendert wird	wie man Zugriff auf z.B. gefolgte Seiten haben wird	wie man Details der dazugehörigen Kollegen und Besitzer von Dokumenten sehen kann

Auch ein Thema zum intelligenten Intranet ist das neue Microsoft Flow. Dies ist eine Art Workflow-Designer, mit dem man einfache Abläufe und Prozesslogiken direkt im Browser erstellen kann. Ebenos einfach soll das Erstellen von Unternehmens-Apps (Power Apps) funktionieren. Gezeigt wurde dies an einem Beispiel für die Genehmigung von Vertriebs-Verträgen.

Security, Privacy and Compliance:
In Sachen Privatsphäre und Datenschutz haben wir bereits ein paar Neuerungen weiter oben beim Erstellen neuer Seiten gesehen. Weiter hinzu kommt die zentrale Überwachung von Apps and Programmen, die per Unternehmensrichtlinien gesteuert werden können. So kann beispielsweise das Kopieren von Inhalten über Apps hinweg unterbunden werden, damit keine sensiblen Daten das Unternehmen ungewollt verlassen können.

Zusätzlich können diese Apps mit einem weiteren PIN als 2-Faktor-Authentifizierung versehen werden. Wird ein Handy also gestohlen und entsperrt, so schützt der zusätzliche PIN in den verwalteten Apps die möglicherweise sensiblen Unternehmensdaten, bevor sie in falsche Hände geraten. Also ein toller weiterer Schritt für die Sicherheit von Unternehmen im Zeitalter von mobilem Zugriff, Home Office und "Bring Your Own Device".

In einem Nebensatz wurde außerdem erwähnt, dass es bald möglich sein wird, Berechtigungen nur temporär zu vergeben. Dies wird alle Sicherheitsprobleme lösen, die bei Werkstudenten, Praktikanten und anderen zeitlich begrenzten Mitarbeitern in Verbindung mit "faulen" ;-) Administratoren entstanden sind.

Open and connected platform:
Als letztes Kernthema wurden die Entwickler adressiert. Über Office Graph soll es einen zentralen API Namespace geben, sodass Entwickler mit nur dieser Schnittstelle Zugriff auf alle Funktionen über die Microsoft-Umgebung haben, egal ob SharePoint, Mail, Yammer etc.

Außerdem wurde verkündet, dass nun Client-Side-Rendering mit Javascript verwendet werden kann. Damit werden nicht nur Dokumentenbibliotheken deutlich schneller angezeigt, sondern auch innerhalb mobiler Seiten und Apps wird die Geschwindigkeit auf diese Weise deutlich besser sein.

On-Premises Version von SharePoint:
Zunächst einmal wurde die generelle Verfügbarkeit von SharePoint Server 2016 verkündet. Microsoft behält dabei Recht, dass diese Version tatsächlich die letzte On-Premises Version sein wird. Aber kein grund zur Sorge. Die Code-Basis zwischen SharePoint Online und On-Premises ist nun gleich, sodass man die neuste Version als "Foundation" für die Zukunft verstehen kann. Also ähnlich wie bei Windows 10, so bleibt auch SharePoint 2016 die letzte Vollversion, die aber kontinuierlich verbessert wird. Dies wird Microsoft ab 2017 mit sogenannten Feature Packs realisieren. Das heißt, Neuerungen erscheinen als erstes in der Cloud, aber man möchte dies auch weitgehend On-Premises zur Verfügung stellen. Ausnahmen können solche Funktionen sein, wie Delve oder Video, die aufgrund der hohen Hardware-Anforderungen nur aus der Cloud zur Verfügung stehen werden, um weiterhin eine gute Nutzererfahrung sicherstellen zu können. Dennoch ist dies eine klare Verpflichtung gegenüber den unternehmenseigenen Umgebungen und beruhigt die Gemüter bei der bisherigen Debatte über den gefühlten Zwang, in die Cloud gehen zu müssen.

Außerdem möchte es Microsoft weiter den Firmen erleichtern, ihre Inhalte nach O365 zu migrieren. Neben der High-Speed-Migration API für die Migration von FileShares sowie der Anbindung von Google Drive als Quelle zur Migration, ist nun auch der Online-Speicher Box verfügbar. Zum Ende des Jahres soll dann sogar SharePoint On-Premises als Quelle für Migrationen nach O365 auswählbar sein. Ein Service, der bisher nur über Drittanbieter möglich war. Allerdings bleibt abzuwarten, was damit alles möglich sein wird. Denn wie bereits die Limitationen bei der FileShare HSM API zeigen, so ist genauso wahrscheinlich, dass auch die Migrationen von den anderen Quelle nur sehr begrenzte Möglichkeiten bieten werden, im Vergleich zu den seit Jahren am Markt etablierten Drittanbieterlösungen. Es ist dennoch ein Schritt in die richtige Richtung, um den Weg in die Cloud zu ebnen.

Ich bin gespannt, wann ich selbst die vorgestellten Neuerungen ausprobieren darf. Ich hoffe, eure Neugier ist genauso geweckt.

Happy "SharePointing"!

---------------------------------------------------------------------------------

Weiterführende Links und Quellen:

• Aufgezeichneter Stream des Events
  https://www.youtube.com/watch?v=0NyxhMlIGeA
• Fokus auf Sicherheit und Compliance
  https://www.youtube.com/watch?v=0mvZr_Gc36U
• SharePoint On-Premises Foundation
  https://blogs.office.com/2016/05/04/sharepoint-server-2016-your-foundation-for-the-future/

1. Nutzerakzeptanz
   Veraltete, nicht mehr aktuelle Dateien tauchen wieder und wieder in den Suchergebnissen von SharePoint auf, obwohl sie die Nutzer nur verwirren. Spätestens, wenn man mindestens auf die Suchergenisseite zwei und drei klicken muss, um endlich das gesuchte Dokument zu finden, hört der Spaß und damit die Nutzerakzeptanz auf. Und das ist kritisch für eine Kollaborationsplattform, da Mitarbeiter sonst erfinderisch werden und andere Wege finden, um Informationen aufzubewahren und zu teilen. An diesem Punkt können wir weiter in datenschutzrechtliche Themen geraten, also kommen wir zu Erklärungsansatz zwei.
2. Rechtssicherheit
   Wenn Mitarbeiter beispielsweise eine veraltete Vorlage für offizielle Verträge mit externen Mitarbeitern verwenden, dann können daraus Schwierigkeiten entstehen. Dies kann oft nur eine Kleinigkeit sein. Aber welchen Umfang dies in einem Rechtsstreit oder einem Image-Verlust bedeutet, ist selten abzusehen.

Wir erkennen also, dass dieses Thema wichtig ist. Grundsätzlich neu ist der Ansatz mit Aufbewahrungsregeln jedoch nicht. Wir kennen bereites Richtlinien für Dateitypen, Seitenrichtlinien, In-Place Records und das Record Center selbst. Diese Ansätze verfolgen bereits ähnliche Ziele. Um aber wieder mehr Klarheit in dieses "Buzz-Word-Bingo" zu bekommen, möchte ich zunächst etwas weiter ausholen und erklären, für welchen Zweck welche Aufbewahrungsrichtlinie geeignet ist und wie sie in das Gesamtkonstrukt passen.

Records Management / In-Place Records:
Fokus:
Archivierung einzelner Dateien
Funktionsweise:
Abhängig von den gemachten Einstellungen werden die zu archivierenden Dateien entweder automatisch in ein Record Center verschoben und verschwinden damit aus SharePoint oder sie werden am aktuellen Ort archiviert und schreibgeschützt.
Anwendungsbeispiel:
Aufbewahrung und Archivierung (durch rechtliche Vorgaben) einzelner Dateien und gleichzeitig SharePoint-Inhalte aktuell halten

Richtlinien für Dateitypen (Information-Management Richtlinien)
Fokus:
Aufbewahrung/Löschung und andere Aktionen (Auditierung, Barcodes, Labels) von Dateien
Funktionsweise:
Nachdem ein Aufbewahrungsregel (Erstellt - zuletzt bearbeitet - als Record deklariert) ausgelöst wird, können folgende Aktionen mit dem jeweiligen Dokument ausgeführt werden:
- in Papierkorb verschieben
- dauerhaft Löschen
- zu einem anderem Ort verschieben
- Workflow starten
- zur nächsten Aufbewahrungsstufe springen
- als Record deklarieren
- vorherigen Entwurf löschen
- alle vorherigen Entwürfe löschen
*Hinweis: Richtlinien für Dateitypen werden auf Site Collection Ebene definiert und gelten dann standardmäßig für alle Inhalte dieses Bereichs. Für ein farm-weites Management können die Dateitypen und entsprechende Richtlinien sogar in einem zentralen Content-Type-Hub verwaltet werden und dann je Web Application vererbt werden. Zusätzlich können diese Richtlinien aber auch auf Listen- und Bibliothekenebene überschrieben werden, sollten für eine Bibliothek andere Regeln gelten.
Anwendungsbeispiel: Zusätzliche Automatisierung des Record Managements, aber auch Anwendung zusätzlicher Aktionen bei beispielsweise Vertragsdokumenten oder CAD-Zeichnungen, um SharePoint "sauber" zu halten und Inhalte zu strukturieren

Richtlinien für Seiten
Fokus:
Aufbewahrung/Löschung ganzer Seiten innerhalb einer Site Collection
Funktionsweise:
Wenn eine Aufbewahrungsregel für eine Seite ausgelöst wird, kann zunächst der Schreibzugriff verweigert werden, Erinnerungen an Seitenbesitzer versendet werden und die Seite auch komplett automatisch gelöscht werden
Anwendungsbeispiel:
Projektseiten mit bestimmter Laufzeit ohne Archievierungsbedarf direkt löschen, um SharePoint aktuell zu halten

Richtlinien zur Dokumentenlöschung
Fokus:
Aufbewahrung/Löschung einzelner Dokumente, aber Farm-weit für bestimmte Vorlagen
Funktionsweise:
Ähnlich wie bei den Richtlinien für Dokumententypen, fokussiert diese neue Governance-Funktion aber nur auf die Aufbewahrung/Löschung einzelner Dokumente, dies jedoch zentral für ein oder mehrere Seitenvorlagen
Anwendungsbeispiel:
OneDrive for Business oder unstrukturierte Team-Seiten "sauber" und aktuell halten

Die Übersicht zeigt deutlich, für welchen Bereich, welche Richtlinien wirken. Nutzen Sie also diese Möglichkeiten, um den SharePoint zu verwalten und obigen zwei Problemen zu begegnen. Der zusätzliche Vorteil an den Richtlinien ist die zentrale Verwaltung. Das gilt insbesondere für die neuen Richtlinien in SharePoint 2016.
Beispiel: Sollten sich für Ihr Unternehmen die Aufbewahrungsregeln von veralteten Datein ändern, müssen Sie dies nur einmal tun und es wird automatisch dort angepasst, wo eine entsprechende Vorlage verwendet wurde.

Der Nachteil jedoch an so vielen verschiedenen Richtlinien ist, dass sie sich gegenseitig überschreiben können. Schauen Sie also genau hin, welche Richtlinie welche Aufbewahrungsregel beinhaltet.

Im folgenden möchte ich nun zeigen, welche Schritte für die neuen Dokumenten-Aufbewahrungsregeln in SharePoint 2016 nötig sind.

Voraussetzungen:
a) Search Service Application
b) Beispieldateien, die wir x Tage nicht bearbeiten
c) Crawl der entsprechenden Bereiche, wo die obigen Dateien liegen
d) Site Collection mit der Compliance Policy Center Vorlage

Diese Punkte haben wir schon in den beiden vorherigen Beiträgen besprochen. Auch der Prozess der Erstellung und Zuweisung zu existierenden Seiten oder sogar Seiten-Vorlagen und OneDrive for Business funktioniert ähnlich wie mit den DLP Regeln im Compliance Center. Dies schauen wir uns aber nachfolgend in den Screenshots an.

Anlegen einer Aufbewahrungsregel

Im Compliance Policy Center, dass wir im letzten Beitrag erstellt haben, wählen wir dieses mal die erste Option, nämlich die Richtlinien für das Löschen von Inhalten.

Simultan zum Compliance Management müssen wir auch hier zunächst die Aufbewahrungsrichtlinien definieren, bevor wir sie einer Vorlage oder einer Site Collection zuweisen können.

Beim Anlegen vergeben wir der Richtlinie einen aussagekräftigen Namen, um sie später eindeutig wiederfinden zu können. Dieser Richtlinie fügen wir anschließend einzelne Regeln hinzu. Diese erhalten ebenso einen Namen.

Bei den Aktionen kann ich wählen zwischen dem Löschen in den Papierkorb oder dem sofortigen Löschen. Als Auslöser für diese Aktionen können das Datum der Dokumenterstellung oder der letzten Änderung gewählt werden sowie die dazugehörige Ablaufzeit.

Wichtig ist hierbei noch die kleine Checkbox, ob die Regel als Standard definiert werden soll. Innerhalb einer Richtlinie kann logischer Weise immer nur eine Regel als Standard definiert werden. Was es mit dieser Standard-Definition auf sich hat, erkläre ich weiter unten.

So sieht dann das Ergebnis aus, wenn ich einer Richtlinie mehrere Regeln (im Screenshot sind es drei) zugewiesen habe. Danach nur noch abspeichern und bei Bedarf für weitere Regelkombinationen wiederholen.

Die Zuweisung von Richtlinien auf eine Vorlage oder eine bestimmte Site Collection ist identisch. Die Screenshots zeigen den Weg für die Anwendung auf eine Seitenvorlage. Dies ist ebenso analog wie zu den Compliance Richtlinien, das heißt, ich kann nur eine einzige Vorlage oder Site Collection auf einmal auswählen.

Aber bei der Auswahl der zu wählenden Richtlinien kann ich nun mehrere auf einmal zuweisen. Ebenso kann ausgewählt werden, welche dieser Richtlinien als Standard definiert werden sollen.

Was bedeuten nun diese Standards? Die Standardregel einer Standardrichtlinie wird automatisch auf eine Site Collection oder entsprechende Seitenvorlage angewendet. Der Seitenbesitzer, kann dies aber nachträglich ändern und sich für seine Seite für eine andere Richtlinie entscheiden. Daher ist es wichtig zu wissen, dass in flexiblen SharePoint-Infrastrukturen auch mehrere Richtlinien und Regeln einer Seitenvorlage zugeordnet werden sollten. Möchte ich als Administrator nur eine Richtlinie pro Vorlage zulassen, dann ist dies natürlich auch möglich. Zusätzlich kann ich das Konstrukt sogar als Pflichtrichtlinie definieren, sodass die entsprechende Regel auch ganz sicher durchgesetzt wird und die Seitenbesitzer nicht die Gelegenheit bekommen, eine Richtlinie abzuwählen.

Sobald eine Richtline zugewiesen wurde, kann es bis zu 24 Stunden dauern, bis diese aktiv wird. Auch erst dann erscheint in den Seiteneinstellungen ein zusätzlicher Link, hinter dem Seitenbesitzer die Richtlinieneinstellungen ändern könnten (wenn sie wollen und dürfen).

Alles in allem gefällt mir diese Funktionalität sehr gut. Jedoch sollte man genau darüber nachdenken, ob man Inhalte automatisch löschen lassen möchte. Obwohl ich ein Freund eines sauberen und strukturierten SharePoints bin, so ist eine permanent gelöschte Datei auch wirklich weg. Überlegen Sie daher genau, welche Richtlinie in welchem Bereich für Sie Sinn macht. Sicherer sind stattdessen Archivierungslösungen mit weiteren nützlichen Regeln, die eine Wiederherstellung mit allen Metadaten ermöglichen können. Solche Lösungen haben Drittanbieter, wie z.B. AvePoint, im Portfolio.

Viel Spaß beim "SharePointen"!

Zu diesem Fest möchte ich euch ein paar kleinere Funktionen in SharePoint 2016 zeigen, über die bisher noch nicht so intensiv diskutiert wurde - man möchte fast sagen, es gibt ein paar kleine versteckte Ostereier, die wir nun gemeinsamen finden möchten.

1. Automatische QR Codes für SharePoint Objekte

Microsoft hat viel am Look and Feel geschraubt, um den neuen SharePoint auch freundlicher bei mobiler Nutzung zu machen. Es ist dennoch sehr mühsam, sich mit einem Handy oder einem anderem mobilen Gerät, durch die Struktur des SharePoints zu hangeln. In SharePoint 2013 gab es daher schon eine kleine Lösung im Codeplex, die per Click einen  QR Code (Quick Response) erzeugt hat. So ein QR Code ist ein zweidimensionales Muster, das mit einer Handy-App und der Kamera eingescannt wird und normalerweise nach der "Übersetzung" einen Link generiert, der dann direkt zu dem enstsprechenden Objekt navigiert. Eine sehr schöne Erleichterung.

In SharePoint 2016 ist diese kleine aber feine Funktion nun direkt eingebaut und man findet sie im Kontextmenü der entsprechenden Objekte einer Liste oder Bibliothek. Dies hilft sehr, wenn man noch schnell ein Dokument auf dem Handy lesen möchte, aber schon den Arbeitsplatz verlassen muss. In SP2016 ist fix der Code generiert, mit dem Handy eingescannt und schon wird das Dokument mit dem mobilen Gerät geöffnet. Vorraussetzung ist natürlich, ein Handy mit Kamera und entsprechender App (normalerweise standard in fast jedem mobilen Browser). Außerdem muss man sich mit dem Handy im Unternehmensnetzwerk befinden oder der SharePoint bzw. das einzelne Objekt ist auch über das Internet extern zugänglich.

2. Einen Ordner erstellen und direkt teilen

Ein weiter Fokus wurde von Microsoft auf die "Moderne Zusammenarbeit" gelegt. Ein Beispiel dafür ist das erstellen eines neuen Ordners in einer Dokumentenbibliothek. Daber können nun direkt Nutzer oder Gruppen mit eingetragen werden, die Zugriff auf diesen Ordner erhalten sollen. Dies reduziert den administrativen Aufwand bei entsprechenden Berechtigungsstrukturen um einige Klicks. Ich finde, auch diese kleine Verbesserung ist gut gelungen.

3. Das Pinnen von Seiten

Wir können Seiten folgen - na klar, das ist keine Neuerung! Aber dabei kann auch schnell mal eine recht lange Liste an Seiten zusammen kommen. In SharePoint 2016 hat Microsoft daher eine weitere Option zum "Sortieren" der gefolgten Seiten eingeführt. Man kann nun einzelne Seiten "pinnen", was bedeutet, dass diese Seiten ganz nach oben in der Liste der gefolgten Seiten wandern. Auch eine schöne Funktion, um etwas mehr Übersichtlichkeit da rein zu bringen, was die Social Features unter Umständen unordentlich machen können.

Aber nun viel Spaß bei der echten Eiersuche und spätestens ab Dienstag wieder "Happy SharePointing"!

2. DLP im neuen Compliance Center

 Mit der eDoscovery im ersten Teil konnten wir bereits überprüfen, dass unsere SharePoint Suche die gwünschten Dokumente findet und die DLP-Filter die sensitiven Daten daraus erkennen. Ich empfehle, dass Sie bei der Anwendung neuer DLP Richtlinien zunächst immer die Regeln im eDiscovery testen, um so auch heraus zu finden, in welchen Bereichen bzw. auf welchen Site Collections entsprechende Regeln angewendet werden müssen. So können Sie gezielte Richtlinien für bestimmte Bereiche ausrollen. In unserem Beispiel setzen wir die Suche nach Kreditkarteninformationen auf unserer Accounting-Seite fort.

Um nun Compliance Richtlinien anzuwenden, müssen folgende Voraussetzungen erfüllt sein:

a)      Konfigurierte Search Service Application
b)      Beispieldatei mit Kreditkarteninformationen
c)      Crawl der entsprechenden Bereiche, wo die obigen Dateien liegen
d)      Outgoing Email ist konfiguriert (optional)
e)      Site Collection mit der Compliance Policy Center Vorlage

Die Punkte a) bis c) habe ich bereits im ersten Beitrag erläutert.

d) Outgoing Email ist konfiguriert (optional)
Dieser Punkt ist optional, aber zu empfehlen, um auch die sehr hilfreichen Email-Informationen zu erhalten, sollte man gegen eine angewendete DLP Richtlinien mit einem hochgeladenen Dokument verstoßen haben. Die Konfiguration für zu sendende Emails ist die gleiche, wie in SharePoint 2013: In der Central Administration navigieren Sie dafür in die "System Settings" und finden dort in der Kategorie "E-Mail and Text Messages (SMS)" den Link zu "Configure outgoing e-mail settings".

Die Möglichkeit, nun auch Emails verschlüsselt zu versenden, ist eine Option, die neu in SharePoint 2016 hinzu gekommen ist. Die Konfiguration ist aber selbsterklärend, sodass wir darauf nicht weiter im Detail eingehen brauchen.

e) Site Collection mit der Compliance Policy Center Vorlage
Auch hier gibt es nichts besonderes zu beachten, also einfach erstellen und dann kann es auch schon losgehen.

Anlegen einer DLP Policy im Compliance Policy Center

Im Compliance Policy Center gibt es zwei Optionen. Die erste, nämlich Richtlinien für das Löschen von Inhalten, geht mehr in die Richtung Governance. Dieses Thema schauen wir uns im dritten Teil genauer an. Wir konzentrieren uns nun auf die Data Loss Prevention Richtlinien.

Für den ersten Teil eines erfolgreichen Compliance Managements, müssen wir uns zunächst DLP Richtlinien definieren, nach denen sensitive Informationen identifiziert werden sollen.

Der Vorgang ist dabei sehr ähnlich, wie zur eDiscovery. Wir vergeben der Richtlinie einen Namen, wählen eine Vorlage aus und legen fest, wie häufig mindestens ein Verstoß gegen die Vorlage (PCI Data Security Standard -> Credit Card Numbers) gefunden werden muss, damit entsprechende Dokumente als sensitiv eingestuft und entsprechende Aktionen vorgneommen werden sollen.

Neu sind dabei im Compliance Center die zusätzlichen Aktionen, die nun bei einem Fund ausgeführt werden können. Der Policy Tip ist ein Hinweis auf einen Verstoß. Er wird in der Objekt-Vorschau angezeigt, aber auch mit Office 2016 direkt im enstprechenden Client. Ein cooles Beispiel dazu finden Sie hier: Policy Tipps im Office Client basierend auf O36 Außerdem können wir aktiv die Datei blockieren, sodass sie Unbefugte nicht länger öffnen können. Nur noch der Anwender, der das Dokument als letztes geändert und damit den Verstoß erzeugt hat, sowie der Dokument-Besitzer und Site Administrator werden noch in der Lage sein, das Dokument zu sehen und zu ändern.

Anwenden von DLP Richtlinien auf Site Collections

Haben wir uns nun DLP Richtlinien definiert, so müssen diese im zweiten Teil auf Site Collections angewendet werden, die wir überwachen möchten. Diese haben wir ja bereits im eDiscovery identifiziert.

Im DLP Policy Center starten wir nun also mit einer neuen Zuweisung.

Im ersten Schritt suchen wir nach einer Site Collection und wählen diese dann aus.
Hinweis: Auch das Suchen und Auswählen von Site Collections basiert auf dem Suchindex! Haben Sie also gerade eine ganz frische Seite angelegt und wollen diese nun anlegen, so werden Sie feststellen, dass SharePoint diese nicht findet. Warten Sie daher den nächsten Continous oder Incremental Crawl ab bzw. starten Sie einen Crawl manuell, um die Seite sofort für die Anwendung von DLP Richtlinien verfügbar zu machen.

Im zweiten Schritt weisen wir der gewählten Site Collection eine Richtlinien zu. In meinem Screenshot gibt es nur eine einzige Richtlinien, aber selbst wenn Sie mehrere Richtlinien auf eine Seite anwenden wollen, so müssen Sie (auch in der RTM) viele einzelne 1-zu-1 Zuweisungen erstellen.

Ist dies erledigt, so haben wir unsere DLP Richtlinien erfolgreich angewendet und nun heißt es warten, bis die entsprechenden Timer Jobs die Verstöße in unseren Dokumenten finden. Diese laufen je nach Sensitivität der zu findenden Daten alle 15 Minuten oder bis hin zu alle 24 Stunden.

Ergebnis für Endanwender und Administratoren

Sind diese Jobs durchgelaufen und auch der Suchindex ist aktuell, so sollten wir nicht nur die Policy Tipps sehen, sondern bei geblockten Dokumenten auch ein kleines rotes Icon, dass uns den Status verdeutlicht. Auch per Email sollte uns SharePoint eine Mitteilung gemacht haben, dass ein Objekt mit dem Namen abc.docx gegen eine Unternehmensrichtlinie verstößt - die Richtlinie wird sogar angezeigt, damit kein Frust entsteht, sondern der Nutzer klar und deutlich darüber informiert wird, warum etwas mit seinem Dokument nicht stimmt. Per Link in der Mail kann man direkt zu dem Dokument gelangen und Änderungen vornehmen.

Der Administrator, der bei einem Verstoß einer entsprechenden Regel informiert werden soll (siehe Einstellung oben: administrator@contoso.com), bekommt sogar noch detailliertere Informationen per Email:

• Fundort
• Titel
• Autor
• Person, die als letztes editierte
• Schweregrad
• Regel und Richtlinienname
• Was, wie oft und mit welcher Sicherheit gefunden wurde

Navigiert nun der Administrator oder der entsprechende Endbenutzer (Besitzer oder Person, die als letztes editierte), so hat man zwei Möglichkeiten, das Problem zu lösen

1. man editiert den entsprechenden Teil des Dokuments, der den Fund ausgelöst hat oder
2. man nutzt den Policy Tipp, um den Konflikt für dieses Dokument zu lösen. Microsoft möchte nämlich nicht, dass durch DLP Richtlinien die Zusammenarbeit plötzlich zusammenbricht. Dazu können wir nun a) diesen Fund als Fehler melden, also dass es gar keine sensitiven informationen im Dokument gibt oder b) den Konflikt überschreiben mit einer Begründung, dass zwar sensitive Informationen zu finden sind, aber dies für den Zweck des Dokuments erforderlich ist. Beispielsweise kann dies eine Rechnung mit Zahlungsoptionen, inklusive Kreditkarteninformationen sein.

Ist auf eine der beiden Varianten der Konflikt gelöst worden, so erhält der Anwender zunächst einen Dialog, dass die Aktion nun entsprechend ausgeführt wurde und auch das kleine "Stopp"-Symbol am Dokument verschwindet wieder.

*Hinweis: Im RC, sowie in der RTM funktionieren die Policy Tipps und das Blockieren leider noch nicht mit einem reinen OnPremise Deployment. Daher fehlen dazu auch noch die Screenshots. Auch andere Kleinigkeiten laufen noch nicht wie gewünscht. Sobald diese Probleme behoben sind (hoffentlich spätestens zur GA), werde ich diesen Beitrag aktualisieren und informieren, wie man die DLP mit dem Compliance Center vollständig zum Laufen bekommt.

Bis dahin "Happy SharePointing"!

Den Download könnt ihr von hier starten:
https://www.microsoft.com/en-us/download/details.aspx?id=51493

Ein paar weitere Details und eine kurze Zusammenfassung von Bill Bear über die neuen Features findet ihr hier:
https://blogs.office.com/2016/03/14/sharepoint-2016-rtm-and-the-future-of-sharepoint-event/
https://blogs.office.com/2016/03/14/whats-new-for-admins-in-sharepoint-server-2016/

Ich werde die Version in den nächsten Tagen testen und lasse euch wissen, was es spannendes zu entdecken gibt.

Happy SharePointing!

Wir wollen uns daher in den nächsten Beiträgen anschauen, was diese neuen Funktionen können und was sie für unser Business bedeuten. Heute beginnen wir mit den neuen DLP (Data Lost Prevention – Schutz vor Datenverlust) Queries im eDiscovery und unterteilen die Serien generell in drei Punkte:

1. DLP mit eDiscovery
2. DLP im neuen Compliance Center
3. Aufbewahrungsregeln mit dem Compliance Center

Wenn Sie diese Überschriften lesen, fallen Ihnen vielleicht auch das schon lange existierende eDiscovery Center, die Site Policies oder das Records Management ein. Die Unterscheidung möchte ich kurz klar stellen.

eDiscovery:
Die eDiscovery kommt hauptsächlich aus dem ameriaknischen Raum, weil es dort oft vor Gericht um Patentstreitigkeiten und ähnliches geht. Da immer mehr digitalisiert ist, dienen auch immer häufiger solche Daten als Beweis vor Gericht. Mit der eDiscovery können wir so unseren gesamten SharePoint – und seit SP2013 auch den mit Oauth verbundenen Exchange und Project Server – nach bestimmten Stichwörtern durchsuchen und als „Legal Hold“ exportieren und als Beweis einreichen.

Site Policies:
Dies sind angewandte Richtlinien, bzw. Workflows auf die gesamten Seite, mit denen man Seiten, die eine eingestellte Zeit nicht mehr genutzt wurden, automatisch löschen lassen kann.

Records Management:
Diese Lösung setzt bei den Site Policies an und bezieht sich auf Dokumente und Objekte innerhalb der Seiten. Es ist im Prinzip eine Archivierung von Objekten, die eine bestimmte Zeit nicht genutzt wurden, aber beispielsweise zu Revisionszwecke noch aufbewahrt werden müssen. Solche Objekte werden dann entweder ganzheitlich in ein Record Center verschoben oder in der ursprünglichen Liste oder Bibliothek schreibgeschützt vorgehalten.

Aufbewahrungsregeln im Compliance Center:
Diese Funktion ist eine Erweiterung zu den Site Policies, die man so nun auch auf einzelne Objekte anwenden kann. Zudem kann man solche neuen Regeln nun standardmäßig bestimmten Seitenvorlagen zuweisen. Beispielsweise können für Projektseiten eine Aufbewahrung von 6 Monaten definiert werden, währenddessen die Besitzer jeder Team-Seite erst nach 24 Monaten ohne Modifikation an die nahende Löschung erinnert werden.

Data Lost Prevention (Verhinderung von Datenverlus):
Diese Funktionalität ist ganz neu in SharePoint 2016 und ergänzt die bisherigen Lösungen, sodass Unternehmen nun eine ganzheitliche Strategie entwickeln können, wie sie mit sensitiven Informationen im SharePoint umgehen möchten. Es ist also kein Ersatz der Lebenszyklus-Prozesse, sondern vielmehr eine Möglichkeit, die eigenen Daten gegen Datenschutzrichtlinien zu identifizieren und zu schützen.

Die DLP macht sich die SharePoint Suche zur Nutze und greift zum Identifizieren der Inhalte auf den Index zurück. Dabei wird der Inhalt gegen definierte Richtlinien, z.B. Kreditkarteninformationen, geprüft. Aber dabei soll es nicht bleiben. Für Exchange und O365 kann man bereits aus 80 verschiedenen Test-Vorlagen wählen (https://technet.microsoft.com/de-de/library/jj150541%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396). Für SharePoint 2016 OnPremise (Release Candidate) stehen uns derzeit leider nur zehn zur Vefrügung. Es ist aber zu erwarten, dass wir auch alle diese Richtlinien zur RTM oder spätestens zu einem Service Pack in der OnPremise Version erhalten werden.

Schauen wir uns nun diese Richtlinien genauer an. In der Beschreibung der PCI DSS finden wir, dass es Kreditkarteninformationen schützen soll. Auf der oben erwähnten Seite finden wir dazu folgendes:

Wir sehen, dass die DLP nach Mustern und bestimmten Schlüsselwörtern prüft. Ein sehr wahrscheinlicher Fund wird aber erst dann protokoliert, wenn bestimmte Kriterien innerhalb von 300 Zeichen gefunden wurden, in diesem Fall ist es die Prüfung der Kreditkartennummer per Luhn-Algorhythmus, der Name der Kreditkartenfirma und des Ablaufdatums. Der Vorteil daran ist, dass nur Dokumente erfasst werden, die wirklich gegen die Unternehmensrichtlinien verstoßen. Zum Beispiel ist ein Dokument, was darüber informiert, welche Kreidtkartenfirmen akzeptiert werden, sicherlich in Ordnung, wohingegen ein Dokument mit mehr als 10 Kreditkartennummern inklusive Kreditfirma und Ablaufdatum deutlich sensibler ist und dementsprechend auch so behandelt werden sollte. Die DLP hilft dabei.

Discovery vs. Policy
Bevore wir uns nun die DLP im eDiscovery anschauen, möchte ich noch kurz den Unterschied zwischen Discovery und Policy erklären.

Discovery (Offenlegung):
Aus meiner Erfahrung haben die wenigsten Firmen einen kompletten Überblick ihrer Daten. Besonders dann, wenn es um potentiell sensible Daten geht. Die Discovery ist dafür perfekt geeignet, um mithilfe von DLP Queries die bestehenden Inhalte zu scannen und der Firma einen Übebrlick darüber zu geben, in welchen Bereichen die Anwendung von Policies (Richtlinien) sinnvoll ist.

Policy:
Eine Richtlinien ist dann die logische Folge der Discovery. Haben wir also erkannt, dass sich auf bestimmten Seiten sensible Daten befinden und Unbefugte darauf Zugriff haben könnten, so wenden wir auf diese Bereiche eine Richtlinie an, damit der Zugriff auf bestehende und neu hinzugefügte Dokument beschränkt wird. Datenschutzbeauftragte können darüber hinaus noch Tipps zur Vermeidung eines Verstoßes, Email-Benachrichtigungen und das Blocken von Inhalten konfigurieren, sobald gegen eine Regel verstoßen wird. Aber dazu später mehr...

1. DLP mit eDiscovery

Kommen wir nun zur Anwendung der DLP mit dem eDiscovery Center. Als Vorraussetzung brauchen wir folgendes:

a)      Konfigurierte Search Service Application
b)      Beispieldatei mit Kreditkarteninformationen
c)      Crawl der entsprechenden Bereiche, wo die obigen Dateien liegen
d)      Site Collection mit der eDiscovery Center Vorlage

a) Konfigurierte Search Sevrice Application
Wie oben bereits erwähnt, basieren die DLP Funktionalitäten auf der SharePoint Suche.
Vorteil:
- Wir brauchen keine zusätzlichen neuen Services und Werkzeuge installieren
Nachteile:
- Echtzeit-Überwachung ist nicht möglich
- In O365 können wir den Crawl nicht forcieren

b) Wir laden unsere Beispieldokumente an einen entsprechenden Ort in SharePoint
Die Datei CC_Many.docx enthält mehrere Kreidtkarteninformationen, während die CC_One.docx nur eine enthält. Dies wird später noch eine Rolle spielen.

c) Wir navigieren zur Search Service Application und starten einen Crawl
Nachdem dieser Crawl durchgelaufen ist, wird auch unsere DLP Query auf die Informationen zugreifen können.

d) Als letzte Vorbereitung benötigen wir eine neue Site Collection mit dem eDiscovery Center als Vorlage

Nachdem unser neues eDiscovery Center erstellt wurde, wollen wir eine neue DLP Query erstellen. Übrigens, Sie können mehrere eDiscovery Center in Ihrer Farm anlegen. So können Sie Beispielsweise auch diese Aufgaben deligieren und enstprechenden Datenbesitzer können ihre Regeln selbst auf ihre Bereiche erstellen und anwenden

.

Anlegen einer DLP Query im eDiscovery Center

Bei der Auswahl der derzeit nur zehn Standard-Regeln nehmen wir die „UK Financial Data“. Der Hintergrund ist, dass diese Regel verschiedene Prüfungen anwendet und wir dies sehr schön in den Ergebnissen sehen werden.

Sehr wichtig bei dieser Auswahl ist auch noch die Konfiguration der Fundhäufigkeit. Standardmäßig werden neun Funde angezeigt. Findet die Regel also nur fünf Übereinstimmungen in einem Dokument, so wird es auch nicht als sensibel eingestuft. Dies ist eine sehr schöne manuelle Anpassung, die der Administrator zu der automatischen Gewichtung vornehmen kann.

Auf der nächsten Seite wird es spannend. Wir sehen oben links die Query, in der zu erkennen ist, dass drei verschiedene Prüfungen durchgeführt werden. Diese können wir auch manuell anpassen und somit die Häufigkeit der Funde von neun auf eins herunter setzen oder auch einzelne Checks entfernen bzw. hinzufügen. Derzeit gibt es noch keine aktuelle Liste der Checks, welche bereits unterstützt werden. Nehmen Sie jedoch eine, die noch nicht unterstützt wird, so erhalten wir beim Ausführen der Query einen Fehler.

Unter der Query-Box können wir den Bereich definieren, in dem gesucht werden soll. Dies kann entweder der gesmate SharePoint oder nur ein bestimmter Bereich sein. Ich habe die Site Collection "Accounting" gewählt.

Wichtig: Der Benutzer, der die Query ausführt, muss Lesezugriff auf alle SharePoint Seiten haben bzw. auf die Seiten, für die er Ergebnisse erhalten möchte.

Im nächsten Screenshot sehen wir in den Staistiken, welche der Prüfungen zu einem Ergebnis geführt haben. Wir können auch erkennen, dass diese Prüfungen nicht nur einzelnd, sondern auch in Kombination durchgeführt werden. Diese Statistiken helfen, meine Queries auf mein Unternehmen anzupassen, um bestmögliche Treffer zu erhalten. Im darauffolgenden ähnlichen Screenshot ist hingegen zu erkennen, dass ich die Häufigkeit der Kreditkartenfunde auf eins gesetzt habe und wir daher auch mehr Ergebnisse erhalten, denn die CC_One.docx ist nun mit dabei. Mit einem Mouse-Over über den Titel der Datei – übrigens der wahre Titel innerhalb des Dokuments wird angezeigt und nicht „CC_One.docx“ – kann ich mir weitere Metadaten dazu anzeigen lassen.

----------

Neben der Query selbst, können wir auch die Suche anhand des Zeitraums und Autor weiter eingrenzen, wenn wir möchten (oben rechts). Nun möchten wir jedoch die Ergebniss exportieren. Dazu klicken wir am unteren Ende des Dialogs auf Export und deifnieren, was in dem Export inkludiert werden soll. Wir können hierbei definieren, ob alle Versionen von gefundenen SharePoint Dokumenten und ob verschlüsselte oder nicht bekannte Dateitypen exportiert werden sollen.

Klickt man dann auf Download Results oder Download Report, so bekommen wir leider noch eine Fehlermeldung des eDiscovery Donwload Managers in dem Release Candidate. Die Application Logs des Event Viewers deuten auf ein Schema-Problem hin. Ich gehe mal davon aus, dass dies noch bis zur RTM gelöst wird, da es in der Online-Version problemlos funktioniert.

FYI:
Description: The element 'Source' in namespace 'http://schemas.microsoft.com/Discovery/ExportConfigSchema' has invalid child element 'SearchEverything' in namespace 'http://schemas.microsoft.com/Discovery/ExportConfigSchema'. List of possible elements expected: 'Endpoint, Custodians' in namespace 'http://schemas.microsoft.com/Discovery/ExportConfigSchema'.
Type: System.Xml.Schema.XmlSchemaValidationException
StackTrace:    at Microsoft.Office.Client.Discovery.ExportConfig.ValidateXmlManifest(Stream configStream)
  at Microsoft.Office.Client.Discovery.ExportConfig.Initialize(Stream configStream)
  at Microsoft.Office.Client.Discovery.SharePointExportServerFacade.get_ExportConfig()
  at Microsoft.Office.Client.Discovery.SettingsForm.LoadExportConfig()

Ein Export von SharePoint Online aus dem aktuellen O365 sieht folgendermaßen aus:

Darin werden die Seiten - und darin die Subseiten und Bibliotheken - aufgelistet, in denen ein Fund für eine entsprechende Query protokolliert wurde. Wenn Microsoft den obigen Fehler behoben hat, werden die Protokolle für SharePoint 2016 sicher ähnlich aussehen.

Das soll ein erster Überblick über die neuen DLP Funktionalitäten im eDiscovery Center sein. Sobald sich etwas mit der RTM und Public Release ändert, werde ich den Beitrag aktualisieren. In den nächsten Tagen schauen wir uns dann die DLP im Compliance Center genauer an.

Wenn Sie weitere Informationen teilen möchten, dann freue ich mich über einen Kommentar. Gefällt Ihnen der Betrag, denn freue ich mich über ein 5-Star Rating.

Herzlichen Dank und viel Spaß beim SharePointen.

Auch wenn es natürlich auch 3rd Party Software gibt, welche unsere Rechner-Systeme überwachen kann, so bringt Windows Server aber bereits selbst sehr viele Messgrößen mit, die man ganz einfach mit dem mitgelieferten Performance Monitor (perfmon.exe) überwachen kann. Um sich nun ein Collector Set anzulegen, gehen Sie folgendermaßen vor.

1. Im PerfMon-Fenster navigieren Sie zu den Data Collector Sets > User Definied. Mit einem Rechtsklick oder über den Button oben im Fenster beginnen Sie, ein neues Set anzulegen.

2. Vergeben Sie dem Set einen aussagekräftigen Namen und wählen Sie, ob Sie mit einer Vorlage oder mit einem leeren Set starten möchten. Haben Sie bereits ein Collector Set angelegt (als xml-Datei gespeichert), so können Sie auch dieses als Vorlage auswählen. Hinweis: Ein unter Windows Server 2012 angelegtes Set kann zwar in frühere Serverversionen eingelesen werden, jedoch kann es nicht gestartet werden. Bitte beachten Sie dies, wenn Sie ein Set aus einer Vorlage erstellen möchten.

3. Auf der Folgeseite sehen Sie, dass Sie den PerfMon auch als Werkzeug nutzen können, um sich beim Über- oder Unterschreiten eines Grenzwertes informieren zu lassen. Auch andere Aktionen können ausgeführt werden. Dies ist natürlich ein sehr schöner Ansatz, um pro-aktiv die Systeme zu überwachen.

Ebenso können Sie aber auch re-aktiv z.B. Daten über Registry-Einträge („System Configuration Information“) oder Events verschiedener Dienste wie exemplarisch der Firewall („Event Trace Data“) sammeln und überwachen. Und dies gilt auch für den Performance Counter Fall, den ich beschreiben möchte. Dafür haben wir folgendes Szenario: Unser SharePoint ist bereits langsam und nun wollen wir heraus finden, woran es liegt. Wir wählen also die Performance Counter.

4. Auf der Folgeseite können wir nun unsere verschiedenen Counter auswählen. Welche ich für SharePoint empfehle, können Sie in meinem Adventskalender, Türchen 9-12, nachlesen (Bsp.: http://blogs.msdn.com/b/robert_mulsow/archive/2015/12/09/sharepoint-performance-monitoring-performance-counter-f-252-r-den-prozessor.aspx). Bitte achten Sie darauf, dass Sie in diesem Fenster auch die Intervallzeit einstellen. Ich empfehle bei längeren Überwachungen ein Intervall von 60 Sekunden. Damit wachsen die Logs auf nicht mehr als wenige MB an, wenn Sie einen Überwachungszeitraum von 24 Stunden wählen.

5. Ganz wichtig bei der Auswahl der Counter ist, für welche Quellen die Daten aufgezeichnet werden sollen. Zum Beispiel haben unsere Server mehr als eine Netzwerkkarte oder mehr als ein Laufwerk. Möchte Sie beispielsweise ein Problem bei den Disk I/Ops überwachen und wählen „_Total“ aus, dann wird der Durchschnitt über alle Laufwerke gesammelt. Sind also vier von fünf Laufwerken optimal eingerichtet, aber das Fünfte und vielleicht Wichtigste ist es eben nicht mit einer Disk Queue Length von über 10, dann komme Sie bei der Auswertung leider nicht der Ursache für eine langsame SharePoint Performance auf die Schliche. Achten Sie also darauf, dass Sie wirklich die einzelnen Laufwerke auswählen. In meinem Screenshot sind dies die Laufwerke C: und D:, die ich überwachen möchten.

6. Haben Sie alle Counter ausgewählt, dann können Sie auf der Folgeseite noch den Ort auswählen, wo die Logs gespeichert werden sollen.

7. Im letzten Schritt achten Sie bitte darauf, unter welchem Benutzer die Daten gesammelt werden sollen. Standardmäßig ist dies der lokale System Account.

Die Auswahl des Benutzers ist besonders wichtig, wenn die Daten zusätzlich für andere Computer in einem Set gesammelt werden sollen. Unter Schritt fünf können Sie im Screenshot erkennen, dass die Daten für den „Local Computer“ gesammelt werden. Wenn Sie jedoch auch Daten von anderen Computern sammeln möchten, muss der Benutzer auch über die entsprechenden Rechte auf den anderen Rechnern verfügen. Der lokale System Account hat diese Rechte natürlich nicht. Verwenden Sie also einen Benutzer, der sich auf den anderen Rechnern auch in den Gruppen „Performance Monitor Users“ und „Performance Log Users“ befindet.

(Auf älteren Windows Systemen Microsoft .NET Framework 2.0 muss zusätzlich der RemoteRegistry Service auf den Rechnern laufen, auf die „aus der Ferne“ zugegriffen werden soll.)

Damit ist das Anlegen des Performance Counter Sets abgeschlossen. Wenn Sie diese Sets nun zu einem bestimmten Zeitpunkt starten möchten, können Sie dies direkt tun, indem Sie diesen manuell starten. Mann kann dies aber auch takten. Dazu empfehle ich, eine Stopp-Kondition zu deifnieren. Das einfachste Beispiel ist das Stoppen nach 24 Stunden.

Anders kann man die Sets auch jeden Tag zu einer bestimmten Zeit starten und nach z.B. vier Stunden stoppen. Ein Szenario, um beispielsweise die Backup Performance jede Nacht zu überwachen.

Welches Szenario Sie auch haben, die zusätzlichen Informationen, die mir der Performance Monitor liefern kann, helfen deifnitiv, um den Ursachen meiner Performance-Probleme auf die Schliche zu kommen. Denn die alte Weisheit „wir brauchen mehr RAM“ löst leider nicht alle Probleme.