<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Troubleshooting on TRUE IT STORIES</title><link>https://true-it-stories.com/tags/troubleshooting/</link><description>Recent content in Troubleshooting on TRUE IT STORIES</description><generator>Hugo</generator><language>de-de</language><lastBuildDate>Fri, 18 Sep 2026 00:00:00 +0200</lastBuildDate><atom:link href="https://true-it-stories.com/tags/troubleshooting/index.xml" rel="self" type="application/rss+xml"/><item><title>208 Bytes, dann Stille</title><link>https://true-it-stories.com/208-bytes-dann-stille/</link><pubDate>Fri, 18 Sep 2026 00:00:00 +0200</pubDate><guid>https://true-it-stories.com/208-bytes-dann-stille/</guid><description>&lt;p&gt;Am zweiten Morgen war der Agent wieder tot.&lt;/p&gt;&#10;&lt;p&gt;Das war der Moment, an dem &lt;a href="https://true-it-stories.com/fehlermeldung-zeigt-auf-das-falsche-problem/"&gt;der erste Teil dieser Geschichte&lt;/a&gt;&#10; 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.&lt;/p&gt;&#10;&lt;p&gt;Bis hierher hatten wir Hypothesen abgearbeitet. Ab hier brauchten wir Beweise.&lt;/p&gt;</description></item><item><title>Die Fehlermeldung, die auf das falsche Problem zeigt</title><link>https://true-it-stories.com/fehlermeldung-zeigt-auf-das-falsche-problem/</link><pubDate>Fri, 18 Sep 2026 00:00:00 +0200</pubDate><guid>https://true-it-stories.com/fehlermeldung-zeigt-auf-das-falsche-problem/</guid><description>&lt;p&gt;Über sechs Maschinen hinweg verlor die Verwaltungsebene unserer Backup-Cloud den Kontakt. Immer dasselbe Bild: Die TCP-Verbindung kam zustande, der Handshake begann, dann sechzig Sekunden Stille — und am Ende die Meldung, das Zertifikat sei nicht vertrauenswürdig.&lt;/p&gt;&#10;&lt;p&gt;Am Wochenende davor hatten wir planmäßig ein SSL-Zertifikat getauscht.&lt;/p&gt;&#10;&lt;p&gt;Diese beiden Sätze haben uns einen halben Tag gekostet.&lt;/p&gt;&#10;&lt;h2 id="sechzig-sekunden-sind-keine-zufallszahl"&gt;Sechzig Sekunden sind keine Zufallszahl&lt;/h2&gt;&#10;&lt;p&gt;Ein echtes Zertifikatsproblem scheitert &lt;strong&gt;sofort&lt;/strong&gt;. Sobald die Kette vorliegt, ist die Prüfung entweder bestanden oder nicht — dafür braucht niemand eine Minute. Sechzigtausend Millisekunden sind kein Messwert, sondern ein konfigurierter Grenzwert. Was so aussieht, ist ein Transportproblem, kein Vertrauensproblem.&lt;/p&gt;</description></item><item><title>Vier Zeichen, die nach einem VMware-Bug aussahen</title><link>https://true-it-stories.com/vier-zeichen-die-nach-einem-vmware-bug-aussahen/</link><pubDate>Fri, 18 Sep 2026 00:00:00 +0200</pubDate><guid>https://true-it-stories.com/vier-zeichen-die-nach-einem-vmware-bug-aussahen/</guid><description>&lt;p&gt;Ein befreundeter Dienstleister rief an. Sein Kunde: ein Betrieb mit rund fünfzig Leuten, drei ESXi-Hosts an einem Dell-Storage, kein vCenter. Ein Datastore war voll und sollte vergrößert werden. Das Volume auf dem Storage war schon erweitert, jetzt fehlte nur noch der Schritt im Host Client.&lt;/p&gt;&#10;&lt;p&gt;Die Oberfläche nahm die neue Größe entgegen, meldete Erfolg — und am Datastore kam nichts an.&lt;/p&gt;&#10;&lt;p&gt;Der Kollege hatte sich beholfen, wie man sich behilft: neue Volumes angelegt statt das alte zu erweitern. Das funktionierte sofort. Aber es erklärte nichts, und irgendwann wollte er wissen, warum.&lt;/p&gt;</description></item></channel></rss>