Der SharePoint Weltuntergang!

Derzeit ist ja die Diskussion darum, dass morgen, am 21.12.2012 die Welt untergehen soll. Auf dieser Diskussion basierend haben Michael und ich uns die Frage gestellt, wie denn ein Weltuntergang in SharePoint aussehen könnte bzw. welche Sachen in SharePoint auf jeden Fall noch vor dem tatsächlichen Weltuntergang gemacht werden sollten, die man sonst nicht tut.
Viel Spaß bei der nicht ganz ernst gemeinten Lektüre unserer SharePoint Weltuntergänge!
ACHTUNG! DIE NACHFOLGENDEN AKTIONEN SIND GEFÄHRLICH FÜR SHAREPOINT. ES WIRD DRINGEND DAVON ABGERATEN DIESE AKTIONEN AUF EIGENEN ODER FREMDEN SHAREPOINT UMGEBUNGEN DURCHZUFÜHREN! AUS SICHERHEITSGRÜNDEN WURDEN DIE AKTIONEN UM KLEINE FEHLER ERGÄNZT, DAMIT DER UNBEDARFTE SHAREPOINT ADMINISTRATOR NICHT VERSEHENTLICH DURCH COPY & PASTE EINEN WELTUNTERGANG AUF SEINEM SHAREPOINT HERBEIFÜHRT. ALLE INFORMATIONEN SIND OHNE GEWÄHR UND GESCHEHEN AUF EIGENE VERANTWORTUNG.

IIS Umleitung auf einen Artikel der „Die Welt“ einrichten

Wir möchten dass alle Anfragen an einem Web-Frontend auf folgenden Artikel der „Die Welt“ umgeleitet werden:
Dies gilt übergreifend für alle Sites am IIS.

  • Internet Information Services (IIS) Manager öffnen
  • Den Servernamen auswählen
  • http Redirect auswählen:

  • Haken bei „Redirect requests to this destination“ auswählen und die o.g. Adresse speichern.
  • Option „Redirect all requests to exact destination (instead of relative to destination“
  • Option Status code “Temporary (307) auswählen, falls die Welt doch nicht unter geht. Oder man verwendet es als April-Scherz.


Erfolgt anschließend ein Zugriff auf SharePoint, wird man zu o.g. Artikel weiter geleitet:

… die Verwirrung ist perfekt!

Die Eine – Die SQL Server Instanz!

Ein sehr fatales Endzeitszenario für SharePoint ist es, wenn man den SQL Server Dienst beendet. Ohne SQL kann SharePoint gar nichts mehr tun, da ja in der SQL Datenbank sowohl SharePoint Konfiguration, als auch die Dateninhalte gespeichert sind. Ist der SQL Server Dienst also beendet, war es das auch für SharePoint.
Für das Stoppen der SQL Server Instanz haben wir uns für einen kleinen PowerShell Befehl entschieden:

Danach funktioniert weder die SharePoint Zentraladministration, noch SharePoint:


Den Index der Volltextsuche zurücksetzen / löschen

Durch ausführen des folgenden Befehls, wird der Index der Search Service Application zurückgesetzt, d.h. gelöscht. Damit steht die Suche keinem Benutzer mehr zur Verfügung, bis der Crawler das nächste Mal den Inhalt crawlt.
Folgender Befehl löscht den Index:

Was anschließend in der Central Administration – Application Management – Manage service applications – Search Service Application:

…man achte auf den “Searchable items” Zähler = 0…

512KB RAM sind genug! – Naja, okay, mit weniger als 16 MB gibt sich eine SQL Instanz nicht zufrieden

Wieder ein Punkt bei dem sich alles um den SQL Server dreht. SharePoint ist einfach sehr stark vom SQL Server abhängig. Daher ist es eigentlich nicht verwunderlich, wenn man den Arbeitsspeicher für die SQL Instanz etwas einschränkt. Der Speicher lässt sich bis 16MB herunterbegrenzen. Das entspricht schon einem ziemlichen Super-GAU für SharePoint, weil dann kaum noch etwas ordentlich funktioniert. Man erhält sehr häufig spannende Fehlermeldungen. Bei 18MB läuft in meiner kleinen Umgebung der SharePoint ohne Fehler, dafür sehr sehr langsam – so stelle ich mir den Weltuntergang in SharePoint vor.
Hier kann der RAM für die SQL Instanz limitiert werden:

Das führt zu sehr langen Wartezeiten beim Laden der Seiten:

Und bei 16MB RAM für die SQL Server Instanz treten schon ernsthafte Fehler auf:

Bye bye my Web Application

So einfach im Sinne von versehentlich geht es nicht, aber dennoch wäre das Löschen einer Web Application für die SharePoint User je nach Inhalt der Weltuntergang. Hier der Befehl zum Löschen einer Web Application mit allem drum und dran – sprich Inhaltsdatenbank und IIS Settings:

Für den Benutzer sieht das Ende so aus:

Nur noch Lesezugriff auf die Web Application erlauben

Wir verbieten neue Inhalte auf Web Application Ebene hinzuzufügen…
Dazu gehen wir in die Central Admin – Application Management – Configure quota and locks:

Option “Adding content prevented” und bestätigen.
Wen ein Benutzer nun versucht ein Dokument hochzuladen, erscheint eine entsprechende Fehlermeldung:

Die web.config vernichten

Die web.config enthält alle IIS-Einstellungen für die Web Application. Diese befindet sich z.B. unter C:inetpubwwwrootwssVirtualDirectories80web.config. Ich habe diese einfach umbenannt, man darf vermuten was passiert…

Der IIS kommt ohne seine Konfiguration nicht mehr zurecht:

Ist direkter Datenbankzugriff ethisch vertretbar?

Jetzt kommt etwas das man niemals tun sollte und ich ernsthaft überlegt habe, ob ich das hier wirklich posten soll. Es ist vielleicht unethisch, trotzdem irgendwie lustig, wenn man einfach mal den Weltuntergang in SharePoint verwirklichen will. Mittels eines SQL Update wird einfach mal nvarchar1 durch einen lustigen Wert ersetzt, z.B. “Weltuntergang 2012”:

Da die Spalte je nach Liste/Library für verschiedene Metadaten Verwendung findet, entwickelt sich das hier zum russischen Roulette. Denn man weiß einfach vorher nicht, welche Daten dadurch beschädigt werden. So passiert es, dass in meiner ISO Liste der Title ersetzt wurde…

Und in meiner Dokumenten Library hat es den “Modified By” erwischt:

Wie dem auch sei, Daten denen man nicht vertrauen kann, sind für den Benutzer der Weltuntergang!
Bitte beachten, dass der Microsoft Support allergisch darauf reagiert, wenn man von Hand in der SQL Datenbank herumdoktert. Also lasst das besser sein!

Den 14er HIVE löschen

SharePoint installiert sich primär in folgendes Verzeichnis (exe, dll, Designs, etc.):
C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14


Wir versuchen nun alle Dateien zu löschen, die nicht gerade in Verwendung sind. Gewisse Prozesse laufen allerdings aus dem Ordner und Log-Dateien sind ebenfalls gesperrt.

SharePoint kommt damit nicht zurecht:

Drop Database

Ein Drop Database ist wohl einer der Kommandos, die so richtig befreiend wirken können. Es sei dann, man stellt plötzlich fest, dass es die falsche Datenbank war.
Gleichzeitig kommt das dem Weltuntergang in SharePoint extrem Nah!
Es ist dann einfach der Inhalt weg, zumindest in Teilen, wenn man mehrere Inhaltsdatenbanken hat. Auch diese Form haben wir natürlich sofort ausprobiert:

Tja, damit kann SharePoint auch diesmal nicht mehr vom Benutzer verwendet werden:


Auch wenn dieser Artikel nicht ernst zu nehmen ist, hoffen wir trotzdem, dass Ihr etwas Spaß daran hattet. Wir haben übrigens wirklich jede der oben genannten Aktionen in unseren SharePoint Umgebungen durchgeführt und können sagen: “Wir sind froh, dass wir mit DocAve unseren SharePoint immer wieder herstellen konnten.”
Achja, und wer noch schöne Möglichkeiten hat um SharePoint mal so richtig kaputt zu machen, die Kommentarfunktion dieses Blog freut sich auf Eure kreativen Einträge.
Frohe Feiertage!
Michael & Dennis

0 0 votes
Article Rating
Teilen

Autor: Dennis Hobmaier

Dennis Hobmaier ist Consultant - Digital Workspace bei Insight Technology Solutions GmbH. Er hat über 15 Jahre Erfahrung in IT-Enterprise Umgebung aller Größenordnungen und bedient Kunden aus den unterschiedlichsten Branchen. Als MCSE SharePoint hat er tiefgreifende Kenntnisse in den Bereichen Microsoft Active Directory, Windows, Azure, SharePoint und Office 365. Gerne teilt er seine Projekterfahrung mit Ihnen.

Subscribe
Notify of
guest

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .

0 Comments
Inline Feedbacks
View all comments