ReportWeb - Planung

Die Entwicklung von ReportWeb erfolgte Iterativ, heute würde man vermutlich Begriffe wie SCUM etc. dafür verwenden. Realistisch betrachtet, wurde aus einem kleinen Script ein etwas größeres Script. Dann wurden Funktionen ausgelagert, dann die Parametrisierung verbessert etc. Wer mag, kann sich auf Reportweb Evolution gerne die verschiedenen Versionen durchlesen. Die Basisüberlegungen blieben dabei unverändert:

• Einfach und Sicher
  Keine durch Client aufrufbare oder anstossbare Skripte mit Parametern, die Sicherheitslücken oder Last verursachen können. Alle Skripte laufen mit einem Dienstkonto, welches idealerweise nur "ReadOnly" auf die Informationen zugreifen kann.
• Statische Skripte, Teile und herrsche
  Ich verzichte absichtlich auch ASP, ASPX, PHP oder andere Dinge, die vom Webserver durch eine Aktion des Benutzers direkt ausgeführt werden. Gerade weil das "Dienstkonto" vielleicht etwas mehr Rechte hat, soll der Webserver die Informationen einfach nur ausliefern aber nicht generieren.
• Formatierung
  So eine nackte Tabelle macht nicht viel her. Also muss eine Lösung her, um die Daten besser zu formatieren, z.B. in dem die Ergebnis in eine HTML-Vorlage eingefügt werden.
• Modular: eigene Berichte sollten einfach zu addieren sein
  Ich habe ja auch eine größere Sammlung wie Get-DAGStatus, CheckADC, CCRMon, CheckDuplicateExternalSID, CheckExObjects, CheckGRP, DumpSPN. Und das ist nur ein Teil. Und jedes mal schreibe ich viel ähnlichen Code zur Ausgabe. Und sie haben vielleicht eigene Berichte.
• Alarmierung
  Ein Bericht muss ja nicht nur eine Ausgabe erzeugen. Wenn beim der Erzeugung eines Berichts ein Fehler festgestellt wird, könne
  z.B. wenn Berichte etwas "komisches" entdecken ?
• Auto Refresh
  Schön wäre ein HTTP-Refresh, damit die Seite immer wieder geladen wird, z.B. als Neartime-Status auf einem billigen Surf-Tablet, welches an die Wand geschraubt ist. Oder als Statusfenster auf einem Überwachungs-PC. Natürlich ist das aber eben nicht Realtime.
• Optional vielleicht Fixen
  Auch wenn das kein Ersatz für ein Provisioning sein kann, aber wenn es "lösbare" Probleme gibt, warum nicht gleich lösen?
• möglichst Einsatz von Bordmitteln
  Die zusätzliche Installation anderer Programme soll vermieden werden. Sicher kann man auf Snapins für Exchange, Lync, ActiveDirectory nicht gänzlich verzichten. Aber für viele Dingen reichen die PowerShell-Basics schon aus
• Einfache Berechtigungen
  Nicht alle Nutzer sollen alles sehen. Dieses Projekt löst dies auf einfache Weise, indem ein Skript diese Aktionen ausführt und als HTML-Datei per Webserver erreichbar macht. Die Authentifizierung übernimmt der IIS, die Berechtigungen können über Verzeichnisrechte gesteuert werden und eine HTML-Vorlage mit Daten zu verknüpfen ist relativ einfach.

Es gilt wieder mal den goldenen Mittelweg zu finden, ein brauchbares Werkzeug zu erhalten ohne dass es zu kompliziert und damit zu schwer zu verwalten wäre. Schließlich würde ich mich freuen, wenn auch Leser vielleicht das ein oder andere Modul beisteuern. Daher habe ich mich an zwei Dingen orientiert.

Sie soll und kann weder ein Provisioning noch ein Monitoring ablösen. Die Idee dahinter ist, dass ein Skript regelmäßig bestimmte Daten ermittelt und die Ausgaben etwas zur Anzeige aufbereitet und vielleicht in dringenden Fällen eine Mail gesendet wird.

Ich weiß, dass ich damit auch Einschränkungen eingehe und den ein oder anderen "Wunsch" nicht erfüllen kann. Aber wenn Sie etwas PowerShell schreiben können, dann ist es ganz einfach, diesen Baukasten um eigene Steine zu erweitern.