v2.37.1 — Technische Korrekturen

Entwickler

• Die Quellcode- und Testextraktion akzeptiert jetzt Leerraum um die Werte von SimpleAdminExtractSources und SimpleAdminExtractTests.
• Bei eingeschalteter Testextraktion nennt der Host-Build fehlende Voraussetzungen und konkrete Abhilfe: deaktivierte Quellcode-Extraktion, fehlende Worker-Testquellen oder fehlende WebUI-Quellen. Die Erfolgsmeldung nennt den vollständigen Pfad der Testprojektdatei.
• Diagnosemeldungen erscheinen höchstens einmal je Projekt-Build; unveränderte Folgebuilds bleiben ruhig. Explizit gemeinsam konfigurierte Quellordner verursachen beim ersten Build keine falsche Warnung wegen der noch ausstehenden WebUI-Extraktion.
• README und Integrationshinweise erläutern Paketversion, Worker-Opt-in, Build-Assets, Restore und den gemeinsamen Quellordner für ausführbare extrahierte Tests.

v2.37.0 — Geplante Tasks überwachen und steuern

SimpleAdmin überwacht jetzt geplante Windows-Tasks, warnt, wenn eine Task auf mehreren oder auf keinem Server aktiv ist, und schaltet Tasks auf Knopfdruck.

Neu

• Seite „Geplante Tasks“ im Menü: Für jede Umgebung eine Übersicht aller überwachten Tasks und Server mit Zustand, letztem und nächstem Lauf und dem Ergebnis des letzten Laufs. Filter nach Umgebung, Text und „Nur Probleme“ bleiben in der Adresse erhalten.
• Nur auf einem Server aktiv: Darf eine Task in einer Umgebung nur auf genau einem Server laufen, meldet SimpleAdmin ein Problem, wenn sie auf mehreren Servern aktiv ist, und ebenso, wenn sie auf keinem aktiv ist. Liefert ein Server gerade keine Daten, erscheint er als „unbekannt“; solange wird „auf keinem aktiv“ nicht gemeldet, weil die Task dort aktiv sein könnte. Tasks, die auf allen Servern laufen dürfen, werden nur einzeln geprüft.
• Fehlgeschlagene Läufe: Endet eine Task mit einem Fehlercode, wird das als Problem gemeldet, mit dem Fehlercode und – soweit bekannt – seiner Bedeutung. Bekannte harmlose Ergebnisse (z. B. „vom Benutzer beendet“) zählen nicht als Fehler.
• Zu lange Laufzeit: Läuft eine Task länger als erlaubt (Standard 2 Stunden), erscheint eine Warnung.
• Verpasste Läufe: Wurde ein geplanter Lauf nicht ausgeführt, erscheint eine Warnung – nicht, solange die Task gerade läuft oder der Zeitpunkt nur knapp überschritten ist. Die Markierung verschwindet, sobald die Task wieder gelaufen ist, spätestens nach 24 Stunden.
• Fehlerereignisse der Aufgabenplanung (z. B. „Start fehlgeschlagen“, „wegen Zeitüberschreitung beendet“) werden gezählt; ein Lauf zählt dabei nur einmal. Ist der Aufgabenverlauf auf einem Server abgeschaltet, weist SimpleAdmin darauf hin („Aufgabenverlauf ist deaktiviert“).
• Ignorieren: Harmlose Ereignisse lassen sich in den Serverdetails mit „Ignorieren“ ausblenden – für 1, 7, 30 oder 90 Tage, bis zu einem Datum oder dauerhaft, immer mit Begründung. Die Regel wirkt sofort und lässt sich unter Einstellungen → Feature-Toggles → Geplante Tasks bearbeiten.
• Steuern mit einem Klick: Angemeldete Benutzer können eine Task direkt aus der Übersicht aktivieren, deaktivieren, starten oder eine laufende Ausführung beenden. Jede Aktion wird vorher bestätigt, danach zeigt die Zelle den aktuellen Stand direkt vom Server.
• „Hier exklusiv aktiv“: Schaltet eine Task auf dem gewählten Server ein und auf allen anderen Servern der Umgebung aus. Schlägt das Ausschalten irgendwo fehl, bleibt der gewählte Server unverändert, damit die Task nie doppelt läuft.
• Verlauf der Aktionen unten auf der Seite: wer wann welche Task auf welchem Server geschaltet hat, mit Ergebnis.
• Serverdetails: neuer Abschnitt „Geplante Tasks“ mit allen Tasks des Servers, ihren Befunden und den letzten Fehlerereignissen. Auch die statischen Statusseiten zeigen die Tasks und das Ergebnis der Prüfung „nur auf einem Server aktiv“.
• Einrichtung pro Server unter Server → Bearbeiten → „Geplante Tasks“ über Task-Muster (z. B. \Minicon\*) mit Ausschlüssen; die Hilfe-Seite hat ein neues Kapitel dazu.

Sicherheit

• Links zu Anleitungen aus der Konfiguration werden nur noch als Link angezeigt, wenn sie auf eine Webseite oder E-Mail-Adresse zeigen. Andere Angaben (z. B. Dateipfade) erscheinen als Text „Anleitung: …“ zum manuellen Öffnen.

Hinweise

• Ist die Anmeldung an der Oberfläche abgeschaltet, ist das Steuern geplanter Tasks gesperrt; die Seite nennt dann den Grund. Die Anzeige bleibt verfügbar.

Entwickler

• Konfiguration (config.json): features.scheduledTasks { enabled, checkIntervalSeconds, defaults { maxRuntimeMinutes (120, 0 = aus), missedRunGraceMinutes (30), allowedResultCodes, eventTimeWindowMinutes (60), eventWarningCount (1), eventCriticalCount (5), maxReportedEvents (50) }, ignoreRules[] { taskPath, eventIds, messageContains, servers, reason, createdBy, expiresAt } }; pro Server checks.scheduledTasks { enabled, checkEvents, tasks[] { pattern, excludePatterns, mode: SingleActive|AllServers, maxRuntimeMinutes, missedRunGraceMinutes, checkMissedRun, allowedResultCodes, failureIsCritical, wikiUrl, remediationSteps } }. Global und pro Server standardmäßig aus.
• Auswahl: Wildcards */? auf dem vollen Pfad; das erste Muster, dessen Include passt, entscheidet, sein Exclude gewinnt (spätere Muster werden nicht mehr geprüft). Tasks unter \Microsoft\ nur mit einem Muster, das selbst mit \Microsoft\ beginnt. Ein Muster ohne Treffer wird als Problem gemeldet.
• Zentrale Gruppenprüfung (WebUI, Notifier, HTML-Generator gleich): Gruppe = gleicher Taskpfad je Umgebung, Server in mehreren Umgebungen nehmen in jeder teil, ohne Umgebung = "". Ein Server gilt als unbekannt bei fehlendem Status, fehlgeschlagener Abfrage oder Status älter als max(notifications.staleThresholdMinutes, 3 × max(general.checkIntervalSeconds, scheduledTasks.checkIntervalSeconds) + 240 s) – general.checkIntervalSeconds muss dem echten Worker-Takt entsprechen. Gruppenprobleme hängen am alphabetisch ersten Teilnehmer der Umgebung laut config.json (dort quittieren); ihr „seit“ steht in schtask-groups-since.json (WebUI: ConfigPath, Notifier: neben notify-state.json).
• WebUI-Host (appsettings.json, Abschnitt ScheduledTasks): ControlEnabled (true), AllowWithoutAuthentication (false; bei Authentication:Enabled=false ist die Steuerung sonst aus), PowerShellPath, ActionTimeoutSeconds (60, 5…600), AuditLogDirectory (Standard: ConfigPath), AuditHistorySize (2000). Audit-Log scheduled-task-actions.json. Jeder angemeldete Benutzer darf steuern; der Start-Log nennt Zustand und ausführendes Konto.
• Rechte: Der Worker braucht lokalen Admin bzw. SYSTEM (sonst fehlen Tasks stillschweigend) und mindestens „Event Log Readers“ für Microsoft-Windows-TaskScheduler/Operational; der Aufgabenverlauf muss aktiviert sein. Die WebUI steuert direkt per PowerShell + CIM über DCOM (kein WinRM): Ihr Dienstkonto braucht auf den Zielservern RPC/DCOM (Firewall-Gruppen „Remote Scheduled Tasks Management“ und WMI), DCOM-/WMI-Remotezugriff und lokalen Admin bzw. Vollzugriff auf den Aufgabenordner. Kein automatisches Failover.
• REST: GET /api/scheduledtasks, GET /api/scheduledtasks/live, POST /api/scheduledtasks/action, POST /api/scheduledtasks/activate-exclusive, GET /api/scheduledtasks/audit, POST /api/scheduledtasksignore (POSTs nur mit JSON-Body; live/action/exclusive liefern 403, solange die Steuerung aus ist).
• RuntimeStatus.ScheduledTasks (ScheduledTaskState) ist im HTTP-Status-JSON enthalten; neue Problem-IDs schtask_*. Logger-Kategorie Minicon.SimpleAdmin.Checkers.ScheduledTasks.
• WebUI: Wiki-/Anleitungs-Links laufen über Display.SafeHref (nur http(s), mailto: und relative Pfade); betrifft Probleme-Seite, Serverdetails und Dateiüberwachung.

Intern

• Neue Bausteine: ScheduledTaskChecker (Checkers), ScheduledTaskGroupEvaluator, ScheduledTaskIgnoreMatcher, ScheduledTaskGroupSinceStore, ScheduledTaskPaths (Shared), ScheduledTaskControlService, ScheduledTaskAuditLog, ScheduledTaskTargets, KeyedAsyncLock, ScheduledTaskProcessRunner (WebUI).
• Tests für Checker-Auswertung, Gruppenprüfung, Problemableitung, Notifier, HTML, Steuerung, REST-API und Einstellungen.

v2.36.1 — Verlässlichere CPU-Werte, Übersichten ohne seitliches Scrollen

Die CPU-Auslastung entspricht jetzt der tatsächlichen Last, und lange Problemtexte passen auf den Bildschirm.

Behoben

• Server meldeten trotz Korrektur in 2.34.1 weiterhin hohe CPU-Last, obwohl sie kaum ausgelastet waren. Die Überwachung misst die CPU jetzt erst, wenn ihre übrigen Prüfungen fertig sind, und nimmt den Durchschnitt über eine Minute. Kurze Spitzen lösen keinen Alarm mehr aus.
• Die Probleme-Übersicht musste bei langen Einträgen (z. B. BizTalk-Orchestrierungen) seitlich gescrollt werden, Status und „Quittieren“ lagen außerhalb des Bildes. Lange Texte brechen jetzt um, alle Spalten bleiben sichtbar.
• Dasselbe gilt für die Liste „Aktive Probleme“ und die BizTalk- und Dateiüberwachungstabellen auf der Serverseite sowie für das Dashboard.
• Die Navigationsleiste ragte bei mittleren Fensterbreiten über den Rand. Sie wechselt jetzt rechtzeitig zum Menü-Knopf, ein langer Anwendungstitel wird gekürzt.

Geändert

• In schmalen Fenstern und auf dem Handy werden Probleme als Karten angezeigt: Schweregrad, Server und Zeit oben, darunter der vollständige Text, unten Status und „Quittieren“.

Hinweise

• Ein Überwachungslauf dauert wegen der einminütigen CPU-Messung etwa eine Minute länger.

Entwickler

• Worker: MetricsCollector läuft nach Task.WhenAll der Checker statt parallel; deren Kindprozesse (powershell.exe, sc.exe, appcmd.exe, netsh) fielen vorher ins Messfenster und wurden vom Eigenanteil nicht erfasst.
• CPU = Mittelwert statt Median. Neue Defaults Metrics:Cpu:WindowMs = 60000 (200 ms … 180 s), Metrics:Cpu:Samples = 12 (2 … 120). Neu Metrics:Cpu:RuntimeBudgetSeconds = 240 (30 … 3600): Fenster wird ab Prozessstart so verkürzt, dass inkl. 30 s Reserve das Budget eingehalten wird, mindestens 1 s. Der CPU-Wert wird je Lauf einmal gemessen und für weitere ServiceTypes wiederverwendet.
• Hosts mit explizit gesetztem Metrics:Cpu:WindowMs behalten ihr Fenster. Läuft der Worker im Minutentakt: Takt verlängern oder Fenster verkürzen, damit sich Läufe nicht überlappen.
• WebUI: .problem-table (fixes Tabellenlayout + <colgroup>, Karten-Grid unter 1200 px, Variante .problem-table-compact für Status/Details), Hilfsklasse .text-wrap-anywhere, Navbar navbar-expand-xl.

Intern

• Tests für Mittelwert, Fensterverkürzung und Konfigurationsgrenzen; Windows-Provider-Test mit kurzem Fenster.

v2.36.0 — Neuigkeiten-Seite

Was ist neu? Die WebUI zeigt jetzt selbst, was sich in jeder Version geändert hat.

Neu

• Seite „Neuigkeiten“: die Änderungen jeder Version (neu, geändert, behoben), die aktuelle Version aufgeklappt, ältere zum Aufklappen.
  • Erreichbar über die Versionsnummer unten links und über die Hilfe-Seite.
  • Nach einem Update erscheint neben der Versionsnummer ein „Neu“-Hinweis; auf der Seite sind die Versionen seit Ihrem letzten Besuch markiert.

Entwickler

• Die Versionshinweise stammen aus der CHANGELOG.md, die in die WebUI-DLL eingebettet ist (passend zur installierten Version, ohne Internetzugriff). Angezeigt werden nur die Abschnitte für Anwender; Entwickler und Intern bleiben ausgeblendet.
• Testprojekt im Host-Quellcode: Mit <SimpleAdminExtractTests>true</SimpleAdminExtractTests> entpackt der Host zusätzlich das Testprojekt nach SimpleAdmin.Sources/Minicon.SimpleAdmin.Tests/ (bei SimpleAdminSourcesNamespace umbenannt, inkl. InternalsVisibleTo). Standardmäßig aus.
  • Das Testprojekt referenziert alle Pakete. Worker- und WebUI-Host müssen dafür denselben SimpleAdminSourcesDirectory verwenden (z. B. ..\SimpleAdmin.Sources); fehlt der WebUI-Quellcode dort, gibt der Build eine Warnung aus.
  • Ausführen mit dotnet test auf dem entpackten Testprojekt (benötigt das .NET SDK). Wie der übrige Quellcode wird es bei einem Paket-Update überschrieben – eigene Tests gehören in ein eigenes Projekt.

Intern

• ChangelogParser (Teilmenge von Markdown, alles HTML-encodiert, nur http(s)- und relative Links) und ChangelogProvider in der WebUI, Tests dazu. Ein Test stellt sicher, dass der oberste CHANGELOG-Eintrag der Paketversion entspricht.
• CHANGELOG nach Zielgruppen aufgeteilt: technische Punkte älterer Versionen in Entwickler verschoben.
• Das Worker-Paket enthält das Testprojekt unter sources-tests/; alle Pakete liefern CHANGELOG.md in sources-root/ mit, damit auch ein aus dem entpackten Quellcode gebauter Host die Neuigkeiten-Seite hat.

v2.35.0 — Domains mit Umgebungszuordnung und Namenskonvention

Domains (DNS-Namen) lassen sich jetzt einer Umgebung, Servern dieser Umgebung und optional einem NetScaler-vServer zuordnen; die Namenskonvention liefert Vorschläge und Warnungen.

Neu

• domains in der config.json: name, environment (Schlüssel aus environments, immer explizit), servers, optional netScalerVServer (mehrere Domains dürfen denselben teilen), healthCheck, description, allowNameMismatch. Fehlt der Block, gilt eine leere Liste.
• Namenskonvention: <name>-dev → development, <name>-ref → ref, <name>-prod und <name> ohne Suffix → production. Beide PROD-Varianten sind eigenständige Einträge mit eigenen Servern und vServern. Weitere Suffixe/Umgebungen über domainSuffixMap (z. B. { "-test": "test" }).
• WebUI-Menüpunkt Domains: Liste gruppiert nach Umgebung mit Filter, Anlegen/Bearbeiten/Löschen. Die Umgebung wird aus dem Namen vorbelegt, die Serverauswahl zeigt nur Server der gewählten Umgebung und aktualisiert sich beim Wechsel. Passt der Name nicht zur Umgebung, wird erst mit „Ausnahme zulassen“ gespeichert.
• Serverliste: Spalte und Filter Umgebung.
• Statische Übersichtsseiten zeigen die Domains jeder Umgebung unter der Umgebungsüberschrift.
• Dokumentation (Hilfe-Seite und documentation.html, Kapitel 19) zu Domains, Konvention, PROD-Varianten, Ausnahme-Flag und domainSuffixMap.

Geändert

• Umbenennen oder Löschen eines Servers pflegt die Serverlisten der Domains mit.

Behoben

• Die zentrale Statusübersicht zeigt jetzt auch Server aus weiteren Umgebungen (bisher nur production, ref, development).

Intern

• DomainNamingConvention (Shared) mit Tests für Suffix-Erkennung, Override-Map, Mismatch/Ausnahme, Deserialisierung und Serverfilter nach Umgebung.

🤖 Generated with Claude Code

v2.34.2 — sc.exe-Argumente korrekt splitten

Behoben

Der Dienst-Installer aus v2.34.0/v2.34.1 schlug beim ersten echten Lauf fehl:

```
[1/5] Dienst 'SimpleAdminWebUI' anlegen …
ERROR: Invalid start= field
Fehler: sc create fehlgeschlagen:
```

sc.exe erwartet Optionsname und Wert als zwei getrennte Argv-Tokens (start= + auto), nicht als ein einzelnes "start= auto". Der Installer bündelte beides in einem ArgumentList-Eintrag, Windows klammerte den Eintrag in Quotes und sc.exe lehnte das zurecht ab.

Fix

binPath=, start=, DisplayName=, obj= und password= werden jetzt zusammen mit ihren Werten als separate Argv-Tokens an sc.exe übergeben. Pfade mit Leerzeichen werden von ProcessStartInfo.ArgumentList wie gewohnt korrekt escaped.

Intern

• Zusätzlicher Unit-Test im Dispatch-Pfad (createCall.Args.Should().ContainInOrder("start=", "auto")) verhindert einen Rückfall.
• Alle sechs Pakete im Lockstep auf 2.34.2.

Empfehlung

Konsument-Wrapper auf 2.34.2 heben, kurz neu publishen, dann <DeineEXE>.exe install --port=5080 als Administrator — der Dienst wird jetzt sauber angelegt und startet.

🤖 Generated with Claude Code

v2.34.1 — CPU-Metrik gegen Selbstkontamination des Workers

Behoben

• Spurious 100-%-CPU-Meldungen auf eigentlich idle Servern. Die Windows-CPU-Messung las % Processor Time mit nur 100 ms Fenster und einer Einzelmessung. Da MetricsCollector in Task.WhenAll parallel zu 10+ Checkern (EventLog-PowerShell, SQL-Probes, AppPool-PerfCounter, HTTP-Probes) läuft und der Worker beim Start zusätzlich JIT/DI-Last erzeugt, landete das Sample fast immer in einem Burst — der Worker mass sich selbst. Die Fehldiagnose erklärt, warum "auf dem Server selbst" niemals 100 % zu sehen waren.

Neu

• Mehrfachabtastung mit Median: Default 3 Samples über 900 ms Fenster statt eines 100-ms-Snapshots. Eine einzelne Burst-Spitze gewinnt nicht mehr.
• Eigenanteil subtrahieren: Process.TotalProcessorTime vor/nach dem Fenster → 100 × self_ms / wall_ms / coreCount wird vom System-Median abgezogen. Clamp [0, 100].
• Prozess-Priorität BelowNormal: SimpleAdminWorkerHost.RunAsync setzt den Worker-Prozess beim Start auf ProcessPriorityClass.BelowNormal. Der Worker darf die echten Workloads nicht verdrängen.
• Konfigurierbar über appsettings.json: Metrics:Cpu:WindowMs (Default 900, Range 200..10 000), Metrics:Cpu:Samples (Default 3, Range 2..20), Metrics:Cpu:SubtractSelf (Default true).
• Debug-Log CPU usage: X% (system median Y%, self Z% over N ms, samples [...]) macht die Herkunft des Endwerts nachvollziehbar.

Intern

• 16 neue Unit-Tests für Median, Clamp, Self-Subtract und Konfigurationsbindung.
• Linux (/proc/stat) und macOS hatten den sauberen Delta-Pfad schon vorher, bleiben unverändert.
• Alle sechs Pakete im Lockstep auf 2.34.1.

Empfehlung

Falls weiterhin auffällig hohe CPU-Werte auftauchen, lassen sich die Defaults ohne Neu-Build nachjustieren — ein Fenster von 1 500 ms mit 5 Samples glättet Server mit sehr vielen gleichzeitigen Checkern noch stärker:

{
  "Metrics": {
    "Cpu": { "WindowMs": 1500, "Samples": 5, "SubtractSelf": true }
  }
}

🤖 Generated with Claude Code

v2.34.0 — Windows-Dienst-Installer und robuste DataProtection-Keys

Neu

• Windows-Dienst-Installer in Minicon.SimpleAdmin.WebUI: SimpleAdminWebUIHost.RunAsync(args) erkennt die Subkommandos install / uninstall / start / stop am ersten Argument und delegiert an ServiceInstaller.Dispatch. Legt in einem Rutsch den Windows-Dienst (sc.exe create binPath=<EigeneEXE>, Autostart), die URL-ACL (netsh http add urlacl), eine Firewall-Regel (netsh advfirewall) und den DataProtection-Keys-Ordner C:\ProgramData\SimpleAdmin\dp-keys an und erteilt dem Dienstkonto per icacls dort Modify-Rechte (OI)(CI)M. Default-Konto LocalSystem; optional --account=DOMAIN\u mit Passwort-Prompt. Flags: --port=5080, --service-name, --display-name, --description, --keys-dir=…, --non-interactive, --purge (nur uninstall, löscht den Keys-Ordner mit).
• Betrieb ohne IIS: Im Windows-Dienst-Modus hostet die Anwendung über HttpSys statt Kestrel, damit Negotiate weiterhin ohne IIS funktioniert. Interaktive Starts (Konsole) und IIS-Deployments bleiben auf Kestrel bzw. In-Process — kein Eingriff ins bestehende IIS-Setup nötig.
• install.cmd als Ein-Klick-Starter neben der Host-EXE.

Geändert

• Neuer Einzeiler-Einstieg für die Host-Anwendung: return await SimpleAdminWebUIHost.RunAsync(args); (parallel zu SimpleAdminWorkerHost.RunAsync). Die bisherige drei-Zeilen-Variante (CreateBuilder → AddSimpleAdminWebUI → UseSimpleAdminWebUI → Run) funktioniert unverändert.
• Alle Package-Versionen im Lockstep auf 2.34.0 gezogen.

Behoben

• DataProtection-Keys hingen am Benutzerprofil des AppPools / Dienstkontos. Nach AppPool-Recycle oder bei blockierter User-Profile-Load crashte die WebUI beim Start mit CryptographicException 0xe0434352 beim Entschlüsseln verwaister User-DPAPI-Keys. AddSimpleAdminWebUI persistiert die Keys jetzt in einem festen Dateisystem-Pfad (Default C:\ProgramData\SimpleAdmin\dp-keys) und verschlüsselt sie mit DPAPI im LocalMachine-Scope (ProtectKeysWithDpapi(protectToLocalMachine: true)). Overrides: DataProtection:KeysDirectory (anderer Pfad) bzw. DataProtection:Enabled = false (zurück zum Framework-Default). Lässt sich das Verzeichnis nicht anlegen, fällt der Host auf das Default-Verhalten zurück und loggt einen Hinweis.

Intern

• Externe Prozessaufrufe des Installers (sc.exe, netsh, icacls) laufen über IProcessRunner; Unit-Tests mocken diese Schicht und decken Argumentparsing, Install-Reihenfolge und Uninstall-Pfad ab.
• Testlauf lokal: 544 bestanden, 2 übersprungen (PowerShell-Integrationstests auf macOS).

🤖 Generated with Claude Code

v2.33.0 — Glossy-Design, Quittieren in der Server-Ansicht, Verlaufsdiagramme

Glossy-Design für die WebUI (Hell/Dunkel), Quittieren direkt in der Server-Ansicht und klickbare Verlaufsdiagramme.

Neu

• Glossy-Design für alle WebUI-Seiten mit Hell/Dunkel-Umschalter in der Navigation (gespeichert im Browser, sonst Systemeinstellung)
• Server-Ansicht: Probleme direkt quittieren / aufheben (gleicher Dialog wie auf der Probleme-Seite), inkl. Lösungsanleitung und Lösungsschritten
• Verlaufsdiagramme: Metrik-Kacheln mit Mini-Verlauf; Klick auf Kachel, Metrik-Badge oder CPU-/Speicher-/Disk-Problem springt zum Diagramm mit Warn-/Kritisch-Linien, aktuell/Ø/Min/Max und Wert je Messpunkt
• Dashboard mit Überwachungsstand: offene und kritische Probleme, nicht gesunde Server, Quittierte, Liste „Aktuell dringend“; Zähler offener Probleme am Menüpunkt Probleme
• Auto-Refresh (60 s) auf Dashboard, Status, Probleme und Server-Ansicht – pausiert bei offenem Dialog, Eingabe oder Hintergrund-Tab
• Anwendungstitel konfigurierbar: Einstellungen → Darstellung (general.title in der config.json)

Geändert

• Status-Übersicht: eine Karte pro Server mit allen Diensten, neue Kachel „Nicht erreichbar“, Filter per Tastatur bedienbar und in der URL
• Einheitlich Ortszeit bzw. relative Zeiten („vor 5 Minuten“) statt UTC; deutsche Status-Bezeichnungen (Gesund, Beeinträchtigt, Kritisch, …)
• NuGet-Abhängigkeiten aktualisiert (MailKit 4.18.1, Microsoft.Data.SqlClient 7.1.1, Microsoft.Extensions.* 10.0.13, …)

Behoben

• Sicherheit: System.Security.Cryptography.Pkcs (transitiv über MimeKit) auf 10.0.13 festgelegt – GHSA-846f-f764-76mx (hoch), GHSA-2fmv-rv2c-59x7
• „Gestoppt seit“ bei AppPools zeigt jetzt auch Tage (vorher fielen sie ab 24 h weg)
• Disk-Problemmeldung: „Disk C:“ statt „Disk C::“ und korrekter Vergleich bei freiem Speicher („<“); Problem-IDs unverändert, bestehende Quittierungen bleiben gültig
• Sprungziel der Charts nicht mehr unter der Navigationsleiste; Debug-Ausgaben aus der Detailansicht entfernt

v2.32.1 — Problem-Startzeit (First/Last) wird gespeichert

Problem-Startzeit (First/Last) wird gespeichert

Behoben

• „First“ und „Last“ eines aktiven Problems waren immer gleich (Zeitpunkt der Seitenerzeugung), obwohl das Problem schon viele Zyklen bestand. Der Worker speichert jetzt pro Problem-ID, seit wann es besteht (RuntimeStatus.ProblemsSince), und führt das jeden Zyklus fort. Statische HTML-Seite, WebUI (Probleme-Seite, Status-Details) und Notifier (inkl. „war seit … aktiv“ in der Behoben-Mail) zeigen die echte Startzeit.
• Problemkarten auf der HTML-Seite zeigen bei Metrik-Problemen nicht mehr cpu: mit leerer Quelle.

Hinweise

• Für bereits bestehende Probleme beginnt die Zeit beim ersten Lauf des neuen Workers.
• Wechselt ein Problem den Schweregrad (Warning → Critical), beginnt die Zeit neu.
• Status-Dateien älterer Worker enthalten das Feld nicht – dort bleibt First = Last.