# Nachtplan-Snapshot 2026-07-21 21:42 — Reboot-Persistenz VM302

**Auftrag (Bär):** Alle laufenden Jobs + Dienste auf VM302 reboot-fest machen (Kopien, Renders,
Watcher, Dienste, CPU+GPU-Last) — ohne zu rebooten, nur Konfiguration + Verifikation.
Zusatz: Pre-Reboot-Snapshot nach Nachtplan (Desktop) UND Forgejo (dieses Repo/diese Datei).

## Ist-Zustand vor dem Eingriff
Ohne AtStartup-Trigger: WasabiSync-VideoTransfer, WasabiSync-U525566 (mcp, gar kein Trigger,
nur manuell gestartet), ModelMigrationToM (mcp, gar kein Trigger), Barby-PseudoWatcher (SYSTEM,
nur TimeTrigger), Barby-MatrixWatcher/-ModelSync/-Heartbeat (mcp, nur TimeTrigger),
BarbyOutputSync (SYSTEM, nur TimeTrigger). Bereits AtStartup: JobLivenessWatchdog,
BarbyOrchestrator, ComfyUI-Server (alle mcp, LogonType Password — Beweis, dass BootTrigger +
Password-Logon grundsätzlich funktioniert, wenn das Konto-Passwort beim Registrieren bekannt ist).

## Durchgeführte Änderungen

### 1) AtStartup-Trigger
- **Barby-PseudoWatcher, BarbyOutputSync** (SYSTEM/ServiceAccount-Logon, kein Passwort nötig):
  direkt per `Set-ScheduledTask` erweitert — bestehender TimeTrigger blieb, BootTrigger + Restart
  3×/1min + StartWhenAvailable ergänzt. Laufende Instanz (BarbyOutputSync) nicht unterbrochen.
- **WasabiSync-VideoTransfer, WasabiSync-U525566, ModelMigrationToM, Barby-MatrixWatcher,
  Barby-ModelSync, Barby-Heartbeat** (mcp/Password-Logon): `Set-ScheduledTask` UND die COM-Route
  (`RegisterTaskDefinition`, auch mit LogonType S4U probiert) scheiterten beide ohne das
  mcp-Kontopasswort ("Der Benutzername oder das Kennwort ist falsch" bzw. Zugriff verweigert bei
  S4U). Windows verlangt bei jeder Neuregistrierung eines Password-Logon-Tasks das Passwort erneut
  — das ist harte Windows-Policy, keine reine Rechte-/Tool-Frage. Passwort wurde NICHT aus dem
  LSA-Secret-Store extrahiert (bewusst unterlassen — das wäre Credential-Dumping, nicht
  Konfiguration). Vaultwarden-Suche nach einem hinterlegten VM302/mcp-Windows-Passwort blieb
  erfolglos.
  → Stattdessen je ein **SYSTEM-Begleit-Task `<Name>-AtBoot`** neu registriert (kein Passwort
  nötig), identische Action, BootTrigger mit 45s Delay, Restart 3×/1-2min, StartWhenAvailable,
  MultipleInstancesPolicy IgnoreNew. Alle Skripte geprüft: keine Abhängigkeit von mcp-Profil oder
  Logon-Session (nutzen feste Pfade M:\, B:\, C:\ProgramData\rclone, localhost-APIs) — Ausnahme
  ModelMigrationToM, siehe Lücke unten.
  Verifiziert: `Get-ScheduledTask` zeigt jetzt bei allen 6 Original-Tasks weiterhin `Boot=False`
  (nicht änderbar ohne Passwort), aber bei allen 6 `-AtBoot`-Begleit-Tasks `Boot=True, Ready`.

### 2) Idempotenz (geprüft, kein Code-Umbau nötig)
- `job-video-transfer.ps1` / `job-u525566.ps1`: `rclone copy` (kein `sync`) — kopiert nur Deltas,
  überspringt bereits identische Dateien. Resume nach Reboot funktioniert von Haus aus.
- `copy-models-to-m.ps1`: `robocopy` ohne `/MIR`, Standardverhalten kopiert nur wenn Ziel fehlt
  oder Quelle neuer/anders ist. Ebenfalls idempotent, kein `/XO` nötig.

### 3) Mounts + AutoLogon (nur geprüft, NICHT verändert — Bär-Auftrag: nicht ungefragt Passwort in
   Registry schreiben)
- `HKLM:\...\Winlogon`: **AutoAdminLogon = 0** (deaktiviert). DefaultUserName=mcp, DefaultDomainName=RDP.
- **Lücke:** R:\ (`WasabiMount`, LogonTrigger mcp) und Z:\ (`RcloneMountStorageboxes`, LogonTrigger
  matthias) sind reine Logon-Mounts. Ohne AutoLogon bleibt nach einem kalten Reboot keine
  interaktive Session automatisch offen → beide Laufwerke bleiben leer, bis sich jemand einloggt.
  `ModelMigrationToM` braucht genau diese beiden Pfade als Quelle (R:\comfyui, Z:\ki-modelle-backup).
  **Vorschlag statt AutoLogon:** wurde geprüft (UNC-Pfade `\\10.10.10.1\vm302-modelle` und
  `\\u618602.your-storagebox.de\backup` sind aktuell erreichbar, aber ob eine SYSTEM-Session ohne
  gecachte Credentials dieselben Freigaben erreicht, ist ungeklärt/nicht getestet ohne echten
  Reboot). Empfehlung: `AutoAdminLogon=1` + DefaultPassword für mcp setzen — **Bär-OK nötig**,
  nicht selbst umgesetzt.
- Wasabi-Mount-Tasks selbst wurden NICHT angefasst (Absprache: das übernimmt der Wasabi-Sync/Mount-
  Agent parallel, keine Überschneidung).

### 4) Boot-Resume-Orchestrator
- Neu: `M:\boot-resume.ps1` + Task `Barby-BootResumeOrchestrator` (SYSTEM, AtStartup, 2min Delay,
  Restart 2×/5min, ExecutionTimeLimit 1h).
- Logik: (1) ModelMigrationToM — prüft ob R:/Z: erreichbar UND ob letzter Lauf im
  Migrations-Log `0 FAIL` meldet; sonst Re-Run (robocopy überspringt Fertiges). (2) Wasabi-Jobs —
  `rclone size` Quelle vs. Ziel, bei Ziel<Quelle und Task nicht schon laufend: `Start-ScheduledTask`.
  (3) ComfyUI-Orchestrator (Port 8197) — wartet bis gesund (max 2min), liest `jobs_state.json`,
  filtert Jobs mit `status=error` + `"neu gestartet"` (= durch einen Neustart abgebrochen),
  schreibt sie nach `M:\boot-resume-pending-jobs.json`. **Kein automatisches Neu-Einreihen per
  Default** (GPU-Zeit/Kosten, Duplikat-Risiko) — Parameter `-ResubmitPendingRenderJobs` vorhanden,
  falls gewünscht.
- **Dry-Run erfolgreich** (2026-07-21 21:30-21:33, `-DryRun`, keine Seiteneffekte):
  - R:\comfyui / Z:\ki-modelle-backup: beide aktuell erreichbar (weil matthias-Session offen ist).
  - ModelMigrationToM: kein "ENDE Migration"-Eintrag im Log → würde Re-Run anstoßen.
  - WasabiSync-VideoTransfer: Quelle 2.340.268.456.018 B, Ziel 133.503.175.414 B (läuft schon,
    State=Running → nicht angefasst, Begleit-Task deckt Kaltstart ab).
  - WasabiSync-U525566: Quelle 225.181.959.871 B, Ziel 210.507.535.710 B (93% fertig, Ready,
    NICHT laufend → würde im Realmodus neu gestartet).
  - Orchestrator: gesund, 1 durch einen früheren Neustart abgebrochener Job gefunden und nach
    `M:\boot-resume-pending-jobs.json` geschrieben.

## Gesamtstatus
**JA, mit einer bekannten Restlücke:** nach einem Reboot laufen ComfyUI-Server, BarbyOrchestrator,
JobLivenessWatchdog (schon vorher AtStartup), alle Barby-Watcher/-Sync (jetzt direkt oder über
`-AtBoot`-Begleit-Task), beide Wasabi-Kopien und der neue Boot-Resume-Orchestrator automatisch an.
**Einzige Ausnahme:** ModelMigrationToM braucht R:\/Z:\, die an interaktive Logons hängen — ohne
AutoLogon (aktuell aus) bleibt das nach einem kalten kompletten kompletten Reboot liegen, bis
sich mcp oder matthias einloggt. Boot-Resume-Orchestrator holt es dann automatisch nach, sobald
die Laufwerke da sind (kein manuelles Nachschieben nötig) — nur der Zeitpunkt ist nicht
"sofort nach Reboot", sondern "sobald jemand eingeloggt ist".

**Kein Reboot durchgeführt.** Alle Aussagen oben sind über `Get-ScheduledTask`, `-DryRun`-Lauf und
direkte Zustandsprüfung (nicht behauptet) verifiziert.