Troubleshooting-Methodik für IT-Support

Warum Methodik statt Rumprobieren?

Jeder im IT-Support kennt die Situation: Ein User ruft an, “der Computer geht nicht”, und du sitzt da mit zehn möglichen Ursachen im Kopf. Wer jetzt blind drauflos probiert – Neustart, Kabel tauschen, Treiber neu installieren – verliert Zeit und übersieht womöglich die eigentliche Ursache.

Strukturiertes Troubleshooting hat drei grosse Vorteile:

1. Schnellere Lösung – Du schliesst systematisch Ursachen aus, statt zufällig zu raten.
2. Reproduzierbarkeit – Andere können dein Vorgehen nachvollziehen und weitermachen.
3. Dokumentierbarkeit – Du kannst jeden Schritt im Ticket festhalten, was beim nächsten ähnlichen Fall hilft.

Diese Seite zeigt dir die bewährte 7-Schritte-Methode, wie das OSI-Modell als Troubleshooting-Leitfaden funktioniert, und gibt dir konkrete Beispiele aus dem KMU-Alltag.

Die 7 Schritte des strukturierten Troubleshootings

Diese Methodik ist an den CompTIA A+/Network+-Standard angelehnt und wird von IT-Pros weltweit eingesetzt.

Schritt 1: Problem genau verstehen

Bevor du irgendetwas anfasst, musst du wissen, was eigentlich los ist. Stelle dem User gezielt Fragen:

• Was passiert genau? Was wird angezeigt / was fehlt?
• Was wurde erwartet?
• Seit wann tritt das Problem auf?
• Was hat sich geändert – Update, neue Hardware, Umzug, Passwortänderung?
• Nur dieser User / nur dieser PC / alle im Büro / alle Standorte?
• Gibt es eine Fehlermeldung – Screenshot oder Foto nehmen lassen.

Beispiel: User sagt “Outlook geht nicht”. Nach Nachfragen: “Seit heute Morgen, nur bei mir, auf dem Laptop zuhause geht es.” Das grenzt das Problem massiv ein – vermutlich kein Exchange-Problem, sondern ein lokales Outlook- oder Netzwerkproblem.

Schritt 2: Problem reproduzieren

Geh selbst an den Rechner (oder per RDP) und stelle das Problem nach. Wenn es nicht reproduzierbar ist:

• Dokumentiere das Verhalten und beobachte weiter.
• Frage nach, wann es zuletzt passiert ist – vielleicht zeigt sich ein Muster (immer morgens, immer nach Login).
• Ein nicht reproduzierbares Problem ist schwer zu lösen – bleib skeptisch.

Schritt 3: Eingrenzen (Divide & Conquer)

Das ist der Kern der Methodik. Statt alles auf einmal anzuschauen, teilst du das System in Abschnitte und testest gezielt:

Das Ziel: den Bereich, in dem der Fehler liegt, immer weiter einschränken.

Schritt 4: Hypothese aufstellen und testen

Jetzt hast du genug Infos für eine begründete Vermutung. Formuliere sie konkret:

“Ich vermute, das Outlook-Profil ist beschädigt, weil das Problem nur bei diesem User auf diesem Gerät auftritt und nach dem gestrigen Update erschienen ist.”

Dann teste eine Änderung auf einmal. Wer drei Dinge gleichzeitig ändert, weiss hinterher nicht, was geholfen hat – und kann das Problem beim nächsten User nicht schnell lösen.

Schritt 5: Lösung umsetzen oder eskalieren

Wenn deine Hypothese sich bestätigt hat, setzt du die Lösung um. Falls du nicht weiterkommst:

• Eskaliere an den nächsten Level (L2, Hersteller, Fachabteilung).
• Gib dem Kollegen eine saubere Übergabe: Was du getestet hast, was du ausgeschlossen hast, wo du stehst.
• Kein Eskalieren ist keine Stärke – unnötig lange auf einem Problem sitzen kostet Zeit und Nerven.

Schritt 6: Vollständige Funktion prüfen

Nachdem du die Lösung umgesetzt hast: Testen, testen, testen.

• Funktioniert das, was vorher kaputt war?
• Hat deine Lösung nichts anderes kaputt gemacht (Seiteneffekte)?
• Ist das Problem nur bei diesem User / PC gelöst, oder muss die Lösung auf mehrere Systeme angewendet werden?

Den User einbeziehen: Lass den User selbst prüfen, ob alles wieder wie erwartet funktioniert. Du siehst vielleicht nicht alles.

Schritt 7: Dokumentieren

Das ist der Schritt, den alle überspringen wollen – und den man am meisten bereut, wenn man ihn weglässt.

Dokumentiere im Ticketsystem oder Wiki:

• Was war das Problem? (Symptom)
• Was war die Ursache? (Root Cause)
• Was war die Lösung? (Fix)
• Zeitaufwand und Datum

Beim nächsten ähnlichen Fall findest du die Lösung in einer Minute statt in einer Stunde.

Das OSI-Modell als Troubleshooting-Leitfaden

Das OSI-Modell ist nicht nur Theorie für Prüfungen – es ist ein hervorragender strukturierter Rahmen für Netzwerk-Troubleshooting. Geh immer von unten nach oben:

Layer 7 – Application   → App-Fehler, Konfiguration, Berechtigungen
Layer 6 – Presentation  → Codecs, Verschlüsselung, Zertifikate
Layer 5 – Session       → Authentifizierung, Sitzungen, Timeouts
Layer 4 – Transport     → TCP/UDP, Ports, Firewall-Regeln
Layer 3 – Network       → IP-Adresse, Routing, Gateway, DNS
Layer 2 – Data Link     → MAC-Adresse, Switch, VLAN, Switchport
Layer 1 – Physical      → Kabel, NIC, WLAN-Signal, Patchfeld

Warum von unten nach oben? Weil Layer-1-Probleme (Kabel nicht drin) alle höheren Layer komplett blockieren. Es bringt nichts, den Proxy zu konfigurieren, wenn das Netzwerkkabel locker ist.

Praxisbeispiel: “Kein Internetzugang”

# Schnellcheck: Netzwerk von unten nach oben
Get-NetAdapter                                    # L1/L2: Adapter-Status
ipconfig /all                                     # L3: IP-Konfiguration
ping 192.168.1.1                                  # L3: Gateway erreichbar?
ping 8.8.8.8                                      # L3: Internet erreichbar (ohne DNS)?
Resolve-DnsName google.com                        # L7: DNS funktioniert?
Test-NetConnection google.com -Port 443           # L4: HTTPS erreichbar?

Häufige Troubleshooting-Szenarien im KMU-Alltag

Szenario 1: User kann sich nicht anmelden

Symptom: "Falsche Anmeldeinformationen" bei Windows-Login

1. Konto gesperrt? → ADUC oder PowerShell prüfen:

   Search-ADAccount -LockedOut | Select Name, SamAccountName
   Get-ADUser mmuster -Properties LockedOut, BadLogonCount

2. Falsches Passwort → Passwort zurücksetzen:

   Set-ADAccountPassword -Identity "mmuster" -Reset -NewPassword (ConvertTo-SecureString "NeuesPasswort123!" -AsPlainText -Force)
   Unlock-ADAccount -Identity "mmuster"

3. Domäne nicht erreichbar → Kann der PC den DC pingen? DNS-Auflösung des DC-Namens testen.
4. Kerberos-Problem → Zeit auf PC und DC abweichend? Maximal 5 Minuten Abweichung erlaubt.

Mehr dazu: Active Directory – User & Gruppen

Szenario 2: Drucker druckt nicht

Symptom: Druckjob hängt in der Warteschlange

1. Spooler-Dienst neu starten:

   Stop-Service -Name Spooler -Force
   Remove-Item -Path "$env:SystemRoot\System32\spool\PRINTERS\*" -Force -Recurse
   Start-Service -Name Spooler

2. Drucker offline? → IP geändert? Drucker neu starten, Port-IP im Druckertreiber prüfen.
3. Treiber-Problem? → Treiber deinstallieren und neu installieren.
4. Netzwerkpfad bei Druckserver? → \\druckserver\druckername erreichbar?

Mehr dazu: Drucker & Netzwerkdrucker

Szenario 3: VPN verbindet, aber interne Ressourcen nicht erreichbar

Symptom: VPN zeigt "verbunden", aber \\server\freigabe ist nicht erreichbar

1. Split Tunneling aktiv? → Nur Firmentraffic durch VPN, oder alles?
2. DNS korrekt? → Bekommt der VPN-Client intern den internen DNS-Server?

   ipconfig /all          # DNS-Server im VPN-Tunnel prüfen
   Resolve-DnsName server.firma.local   # Interner Hostname auflösbar?

3. Routing stimmt? → Interner Adressbereich (z.B. 10.0.0.0/8) über VPN geroutet?
4. Firewall auf dem Zielserver? → Erlaubt Windows Firewall Zugriff aus dem VPN-Subnetz?

Szenario 4: Windows-PC extrem langsam

Symptom: Alles dauert Minuten, CPU oder RAM am Anschlag

1. Task-Manager öffnen (Strg+Shift+Esc): Was frisst CPU/RAM/Disk?
2. Disk-Auslastung 100%? Oft Windows Search oder Antivirus beim Erstscan:

   # Top-Prozesse nach CPU
   Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, CPU, WorkingSet

3. Malware? → Defender-Scan ausführen, ggf. Malwarebytes zusätzlich.
4. RAM zu wenig? → systeminfo zeigt Gesamt-RAM. Unter 8 GB ist heute oft zu wenig.
5. HDD statt SSD? → Get-PhysicalDisk – HDDs sind 2026 ein häufiger Bremsklotz.
6. Startprogramme reduzieren: Win+R → msconfig → Autostart-Tab.

Eskalation: Wann und wie?

Eskalation ist kein Versagen – sie ist professionell. Eskaliere, wenn:

• Du das Problem nach 30–60 Minuten nicht eingrenzen konntest.
• Du spezifisches Fachwissen brauchst (Netzwerk, Datenbank, ERP).
• Die Auswirkung kritisch ist (ganzer Standort ausgefallen, Produktion steht).
• Du zum Test produktive Systeme ändern müsstest.

Übergabe sauber machen:

• Was ist das Symptom?
• Was hast du bereits getestet?
• Was hast du ausgeschlossen?
• Was ist deine aktuelle Hypothese?

Ein L2-Kollege, der eine saubere Übergabe bekommt, braucht keine 30 Minuten, um denselben Stand zu erreichen.

Dokumentation und Wissensmanagement

Gute Dokumentation multipliziert dein Wissen. Jede gelöste Ursache, die im Wiki oder Ticketsystem steht, spart beim nächsten ähnlichen Fall Zeit.

Minimalstruktur für ein Ticket:

Problem:    Outlook-Profil beschädigt nach Update KB5034439
Symptom:    Outlook startet nicht, Fehlermeldung "Profil kann nicht geöffnet werden"
Ursache:    Korruptes OST-Profil durch abgebrochenes Update
Lösung:     OST-Datei gelöscht (%localappdata%\Microsoft\Outlook\),
            Outlook neu geöffnet, Profil neu synchronisiert
Dauer:      ca. 20 Min

Nützliche Diagnose-Tools auf einen Blick

Troubleshooting im PowerShell-Alltag

Einige Befehle, die du beim Troubleshooting immer wieder brauchst:

# === SYSTEMINFO ===
Get-ComputerInfo | Select-Object WindowsProductName, TotalPhysicalMemory, OsLastBootUpTime
systeminfo | findstr /C:"Boot Time" /C:"Total Physical Memory"

# === EVENTS / FEHLERLOG ===
# Letzte 20 Fehler im Systemprotokoll
Get-EventLog -LogName System -EntryType Error -Newest 20 | Select TimeGenerated, Source, Message

# Kritische Events der letzten 24h
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=(Get-Date).AddHours(-24)}

# === NETZWERK DIAGNOSE ===
ipconfig /all                                          # IP-Konfiguration
ipconfig /flushdns                                     # DNS-Cache leeren
Test-NetConnection 8.8.8.8 -Port 53                   # DNS-Port testen
Test-NetConnection fileserver.firma.local -Port 445   # SMB-Freigabe testen

# === DIENSTE ===
Get-Service | Where-Object { $_.Status -eq 'Stopped' -and $_.StartType -eq 'Automatic' }
# Zeigt: Dienste, die automatisch starten sollten, aber gestoppt sind

# === DISK-HEALTH ===
Get-PhysicalDisk | Select FriendlyName, MediaType, HealthStatus, Size

Weiterlernen

• CompTIA: Use a Troubleshooting Methodology for More Efficient IT Support – Fundierter Artikel zur 7-Schritte-Methode
• Microsoft Learn: Fehlerbehebung bei Netzwerkproblemen – Offizielle Doku
• Petri IT Knowledgebase: How to use the OSI Model for Network Troubleshooting – Praxisnahe OSI-Troubleshooting-Anleitung
• Atlassian: Problemmanagement in ITIL – ITIL-Grundlagen für strukturiertes Problem-Management
• Microsoft Sysinternals – Offizielle Docs zur Sysinternals Suite
• PowerShell für IT-Alltag – Wichtige Befehle für die tägliche Arbeit als IT-Allrounder