Windows-Dienste durchsuchen, jede Änderung vorab ansehen und sehen, was seit gestern abgedriftet ist

• Keine Suche. Navigiert wird nur durch den Sprung zum ersten Buchstaben eines Anzeigenamens.
• Kein Filtern. Es gibt keine Möglichkeit zu fragen: Zeige mir, was automatisch starten soll und nicht läuft.
• Eine Zeile nach der anderen. Zwölf Dienste neu zu starten heißt zwölf Rechtsklicks und zwölf Wartezeiten.
• "Wird beendet..." für immer, und der einzige Ausweg ist der Task-Manager samt Raten, welcher Prozess es ist.
• Kein Verlauf. Niemand weiß, wer diesen Starttyp auf Deaktiviert gesetzt hat und wann.
• Verborgene Daten. Prozess, Trigger, Privilegien, Sicherheitsdeskriptor, wer die Programmdatei signiert hat - für alles braucht man sc.exe aus dem Kopf oder die Registrierung.
• Keine Gleichwertigkeit auf der Befehlszeile. sc.exe hat eine Syntax aus den Neunzigern, und das Get-Service, das mit Windows in Windows PowerShell 5.1 kommt, zeigt weder das Konto, unter dem ein Dienst läuft, noch gar seine Beschreibung. PowerShell 7 zeigt beides und wird separat installiert.

$ bws snapshot diff before.json --live --exit-code
Changed (2):
  Spooler  Print Spooler
    startType: Manual -> Automatic
    status: Stopped -> Running  (running state, not configuration)
  wlidsvc  Microsoft Account Sign-in Assistant
    status: Stopped -> Running  (running state, not configuration)

Added 0, removed 0, changed 2. Fields differing: 1 in configuration, 2 in running state.

• Konfiguration und Laufzustand werden getrennt gemeldet. Zwei Snapshots im Abstand eines Tages unterscheiden sich darin, was gerade läuft, und fast nichts davon ist Drift - die Zeile mit dem geänderten Starttyp ist die, die man lesen muss.
• Was sich nicht vergleichen ließ, wird aufgelistet und nicht versteckt. Ein Feld, das ein Snapshot nie gelesen hat, erscheint als not compared, sodass ein Vergleich, der nichts hat sich geändert sagt, bedeutet: nichts hat sich in dem geändert, was beide Seiten sehen konnten.
• --exit-code endet mit 5, wenn sich die Konfiguration unterscheidet, sodass eine geplante Aufgabe bei der Bereitstellung einen Snapshot machen und in der ersten Nacht, in der der Rechner abdriftet, jemanden alarmieren kann.
• Zwei Rechner, zwei Dateien. Machen Sie einen Snapshot auf dem Staging- und einen auf dem Produktivsystem und vergleichen Sie sie irgendwo.

$ bws stop Winmgmt --dry-run --dependents
Plan: stop Winmgmt  (2 steps)
  1. stop  vmms      (would break otherwise)
  2. stop  Winmgmt   (asked for)

Warnings:
  - Stopping Winmgmt also stops one other entry: vmms
  - Winmgmt starts automatically, so it will be back after the next restart.

• Führen Sie es ohne --dry-run aus, und das sind die Schritte, in dieser Reihenfolge, mit denselben Gründen daneben. Es gibt keinen zweiten Codepfad für den Ernstfall.
• Was mit heruntergeht, steht im Plan. Die Dienste, die ausfallen würden, sind eigene Schritte, und ein Plan, der etwas stilllegen würde, das der Rechner braucht, sagt das in seinen Warnungen.
• Eine Ablehnung kommt vor der Schaltfläche. Ein Treiber, ein Dienst, für den der Manager kein Beenden annimmt, ein Prozess, den das System schützt - abgelehnt, wenn der Plan gebaut wird, mit Begründung. Das Fenster graut die Schaltfläche aus und nennt daneben den Grund.
• Erzwungenes Beenden hat zwei Schritte, und der zweite ist bedingt. bws kill bittet den Dienst, sich zu beenden, und beendet seinen Prozess nur, wenn das nicht klappt, und nennt dabei jeden anderen Dienst, der in ihm lebt.