Firmennetz prüfen: Was Sie selbst checken sollten, bevor der IT-Dienstleister kommt

Ein Rechner greift nicht mehr auf die Warenwirtschaft zu, der Bondrucker bleibt stumm, und die Kasse meldet „Keine Verbindung zum Server”. Solche Ausfälle im kleinen Firmennetz haben selten eine einzelne Ursache und fast nie eine, die zufällig auftritt. Bevor Sie zum Hörer greifen, lohnt sich eine systematische Bestandsaufnahme. Die spart nicht nur Geld beim externen Dienstleister, sondern bringt Sie in die Position, beim Anruf präzise sagen zu können, was läuft und was nicht.

IP-Adressen dokumentieren: Wer spricht mit wem?

Fangen Sie bei den Clients an, die ausfallen, und arbeiten Sie sich zum Server vor. Notieren Sie auf jedem betroffenen Rechner die aktuelle IP, Subnetzmaske, das Standardgateway und den DNS-Server. Unter Windows zeigt ipconfig /all alle Details, unter Linux genügt ip addr show und cat /etc/resolv.conf. Vergleichen Sie die Werte mit einem funktionierenden Gerät im selben Subnetz. Weicht die IP ab, oder liegt gar eine APIPA-Adresse wie 169.254.x.x vor, hat der Client keinen Kontakt zum DHCP-Server.

Gerade in gewachsenen Netzen mit statischen und dynamischen Adressen nebeneinander lohnt sich ein sauberes IP-Adressmanagement. Doppelt vergebene Adressen sind ein Klassiker, den arp -a auf Windows oder arp-scan unter Linux in Sekunden entlarvt.

DHCP und DNS: Die unsichtbaren Störquellen

Ein ausgefallener DHCP-Server verhindert, dass neue oder neugestartete Geräte eine Adresse beziehen. Prüfen Sie als Erstes, ob der DHCP-Dienst auf dem zuständigen Server oder Router läuft. Unter Windows sehen Sie das mit Get-Service DhcpServer in der PowerShell, auf einem Linux-DHCP mit systemctl status isc-dhcp-server. Sehen Sie im Lease-Bereich nach, ob der Pool erschöpft ist: Ein voller DHCP-Scope liefert neuen Geräten schlicht keine Adresse mehr.

Parallel dazu prüfen Sie die Namensauflösung. Ein funktionierendes Ping auf eine IP, aber nicht auf den Hostnamen, deutet auf ein DNS-Problem hin. Testen Sie mit nslookup oder dig gegen den internen DNS-Server. Wer DHCP und DNS sauber getrennt und dokumentiert hat, spart sich an dieser Stelle langes Rätselraten.

Switch und Verkabelung: Ein Blick auf die Hardware

Netzwerkausfälle mit wechselnden Symptomen an mehreren Geräten gleichzeitig führen oft zum Switch. Gehen Sie hin und schauen Sie auf die LEDs: Blinken die Ports der betroffenen Geräte grün und synchron, oder flackert ein Port orange oder gar nicht? Ein durchgängig orangefarbener Port kann auf einen auf 10 oder 100 MBit/s heruntergehandelten Link hindeuten, oft verursacht durch ein defektes Kabel oder einen losen Stecker.

Tauschen Sie verdächtige Kabel testweise, auch wenn „das Kabel gestern noch ging”. Prüfen Sie, ob der Switch selbst noch antwortet. Viele managed Switches haben eine Weboberfläche, die Auskunft über Port-Status, Fehlerzähler und PoE-Budget gibt. Bei einfachen unmanaged Switches hilft nur der physische Check: Stromversorgung, Lüftung, Alter des Geräts. Ein Switch, der seit acht Jahren im Kabelschacht arbeitet, ist ein realistischer Kandidat für sporadische Aussetzer.

Protokolle lesen, bevor der Dienstleister anrückt

Die Windows-Ereignisanzeige und die Syslogs Ihrer Linux-Server sind protokollierte Zeugen. Filtern Sie im Event Viewer unter „Windows-Protokolle > System” nach Quellen wie Dhcp-Client, Tcpip oder NetBT im Zeitfenster des Ausfalls. Unter Linux durchsuchen Sie /var/log/syslog oder die Journalctl-Ausgabe nach DHCP-Requests, DNS-Fehlern oder Interface-Flaps. Diese Einträge liefern Zeitstempel, die eine scheinbar zufällige Ausfallserie zu einem reproduzierbaren Muster machen.

Als letzten Schritt vor dem Anruf lassen Sie eine Paketaufzeichnung mitlaufen. Ein kurzer tcpdump-Mitschnitt auf dem Server oder eine Aufzeichnung des Netzwerkverkehrs mit Wireshark auf einem Client zeigt Ihnen, ob ARP-Requests ins Leere laufen, ob der DHCP-Discover unbeantwortet bleibt oder ob ein Gerät den Broadcast mit fehlerhaften Paketen flutet. Protokoll und Paketmitschnitt zusammen geben dem IT-Dienstleister einen klaren Startpunkt, statt ihn mit „Es geht nicht” ins Raten zu schicken.

Wenn Sie nach dieser Checkliste IP-Adressen, DHCP-Status, Switch-Verhalten und aussagekräftige Logs zusammengetragen haben und das Problem damit noch nicht eingegrenzt ist, ist der Einsatz externer Hilfe der richtige nächste Schritt. Ein Dienstleister wie Celtic Informatique arbeitet dann mit verwertbaren Fakten statt mit vagen Fehlerbeschreibungen, und Sie zahlen nur die Analyse, die wirklich nötig ist.

• About
• Latest Posts

Julian Becker

Ich bin Julian Becker, Netzwerkarchitekt bei einer Versicherungsgesellschaft in München. Ich liebe es, komplexe technische Themen verständlich zu machen – deshalb erstelle ich gerne klare Anleitungen und schule meine Kolleginnen und Kollegen regelmäßig. Mein Ziel: Netzwerke so gestalten, dass sie nicht nur funktionieren, sondern auch für alle nachvollziehbar sind.

Latest posts by Julian Becker (see all)

• Firmennetz prüfen: Was Sie selbst checken sollten, bevor der IT-Dienstleister kommt - 11 Juni 2026
• Netzwerkverkehr analysieren mit Wireshark – Einstieg leicht gemacht - 19 März 2026
• IP-Adressmanagement: Best Practices für mehr Übersicht - 12 März 2026