208 Bytes, dann Stille
Am zweiten Morgen war der Agent wieder tot.
Das war der Moment, an dem der erste Teil dieser Geschichte aufhörte, eine Fehlersuche zu sein. Das über Nacht erneut eingespielte Update war wieder herunter, der halb deinstallierte EDR vollständig entfernt, alle Maschinen frisch gestartet und nachweislich sauber. Und der Management-Agent des Cloud-Connect-Servers kam trotzdem nicht mehr an die Veeam Service Provider Console.
Bis hierher hatten wir Hypothesen abgearbeitet. Ab hier brauchten wir Beweise.
Was der Mitschnitt zeigte
Paketmitschnitt auf dem Management-Port, dreimal wiederholt, dreimal identisch: Die TCP-Verbindung steht sauber. Der Agent schickt seinen Handshake. Der Server antwortet — genau einmal, 208 Bytes. Dann nichts mehr. Nach exakt sechzig Sekunden gibt der Agent auf und meldet, das Zertifikat sei nicht vertrauenswürdig.
Während derselbe Serverprozess parallel über hundert andere Agenten fehlerfrei bedient. Nur dieser eine wird nach 208 Bytes abgewürgt.
Das ist ein anderer Befund als „es geht nicht". Es ist ein Befund, der eine Frage stellt: Was ist an diesem einen Agenten anders, dass der Server nach der ersten Antwort schweigt?
Die Leiter, Sprosse für Sprosse
Wir haben alles durchgetestet, was auf unserer Seite ging, und jeden Schritt dokumentiert. Jede ausgeschlossene Möglichkeit war ein Argument, das der Hersteller später nicht mehr vorschlagen konnte.
- Verbindung zurücksetzen. Nichts.
- Beide Server komplett neu starten. Nichts.
- Rekonfiguration aus der Konsole anstoßen. Ergibt einen Henne-Ei-Deadlock: Der Task wartet auf den Reconnect, der Reconnect braucht eine abgeschlossene Registrierung, die der Task erst abschließen würde.
- Reparaturinstallation. Nichts.
- Remote-Deployment aus der Konsole. Nichts.
- Komplette Deinstallation, fabrikneue Installation, Erstregistrierung unter neuer Identität — mit dem Support abgestimmt. Identischer Fehler beim allerersten Handshake.
Die sechste Sprosse hat den Fall gedreht. Ein Agent ohne Vorgeschichte, ohne Altlast, unter neuer Identität — und der Server würgt ihn nach 208 Bytes ab. So unsere Schlussfolgerung damals: Der kaputte Zustand liegt nicht im Agenten, er überlebt Neustarts, also liegt er auf der Serverseite, gebunden an das Objekt dieses Servers. Es gibt keinen Handgriff auf Client-Seite, der das behebt. Wie viel davon stimmte, steht im dritten Teil.
Wir haben die Umgebung eingefroren und alles an die Entwicklung des Herstellers übergeben: Mitschnitte, korrelierte Logs, die dokumentierte Leiter.
Eigene Forensik verwandelt „bitte neu installieren" in ein Ticket für die Entwicklung. Wer Symptome liefert, bekommt Vorschläge. Wer Beweise liefert, bekommt Fixes.
Diese sechste Sprosse hatte übrigens einen Preis, den wir erst zwei Wochen später kennen sollten. Auch dazu im dritten Teil.
Der Übergangsbetrieb
Hinter der Konsole stehen rund dreißig Reseller und etwa fünfhundert Endkunden. Die Sicherungen liefen die ganze Zeit — betroffen war ausschließlich die Verwaltungsebene. Aber über die läuft alles, was ein Reseller täglich braucht: neue Kunden anlegen, Kontingente ändern, Monitoring.
Also ein Übergangsbetrieb, mit dem Hersteller abgestimmt: Neukunden per Ticket an uns, wir legen sie direkt auf der Infrastruktur an, Zugangsdaten zurück, der Kunde sichert am selben Tag. Backup-Richtlinien für reine Agent-Kunden lokal statt über die Konsole. Selbstservice gesperrt — mit der Ansage, welche Fehlermeldung man dort sieht und dass man deswegen kein Ticket aufmachen muss. Und eine lückenlose Übergabeliste für den Tag, an dem die Konsole zurückkommt.
Kein Neukunde hat gewartet.
Der erste gerissene Termin
Der Hersteller sagte ein Update bis zum Monatsende zu. Am Stichtag kam: „still investigating", neuer Termin eine Woche später.
Wir haben das so gesagt, wie es war — nach innen und nach außen. Die Partnermails dieser Wochen folgten alle demselben Muster: zuerst, was stabil ist (die Backups). Dann der ehrliche Stand, auch wenn er lautete „der Hersteller hat den Termin gerissen, das ist für uns nicht akzeptabel". Dann konkrete Handlungsanweisungen. Kein Pathos. Eine Entwurfsfassung, die zu weinerlich geraten war, flog raus, bevor sie einen Partner erreichte.
Und wir haben unseren Distributor informiert, bevor er nachfragen musste. Mit Fallnummer als Beleg und der Frage, wie er die Meldung haben will.
Der Monatswechsel
Seit dem ersten Ausfall hatte die Konsole keine Verbrauchsdaten mehr eingesammelt. Für fünfhundert Kunden. Und der Monatswechsel stand an: Abrechnung an die Reseller, Lizenzmeldung an den Distributor.
Wir haben dem Hersteller eine Frage gestellt, deren Antwort wir vorgaben: Wir werden unsere Lizenzzahlen nicht raten. Die schriftliche Zusage wurde unser Sicherheitsnetz für alles Weitere: Der Monatsbericht darf bis Ende des Folgemonats gelöscht, neu eingesammelt und regeneriert werden.
Abrechnungsfähigkeit gehört vom Hersteller entkoppelt. Eigene Exporte, schriftliche Zusagen — und ein Datum, bis zu dem sich alles korrigieren lässt.
Acht Tage, dann eine Sekunde
Der Hotfix kam als einzelne DLL, hashverifiziert, an zwei Stellen einzuspielen. Ein kleiner Kampf mit Diensten, die sich selbst neu starten, inklusive.
09:18:43 Uhr: Der Agent verbindet. 09:18:44 Uhr: Validierung erfolgreich. Unter einer Sekunde — nach acht Tagen mit Timeouts von sechzig. Die Agenten draußen bei den Kunden verbanden sich von selbst wieder. Der Server schaufelte 123 Megabyte aufgestauten Rückstand ab, CPU auf Anschlag. Am Nachmittag: Status „Healthy".
Wir bereiteten die Erfolgsmeldung vor. Und dann klickten wir noch einmal durch die Konsole.