Når netværket fejler: 5 PowerShell-tjek til hurtigere IT-fejlfinding

HOUSE4IT A/S — Thu, 05 Nov 2026 08:09:25 +0000

En medarbejder fortæller, at internettet ikke virker.

Men hvad betyder det egentlig?

Kan computeren ikke forbinde til Wi-Fi? Virker hjemmesider ikke? Eller er det kun virksomhedens interne system, der er utilgængeligt?

Som IT-tekniker er det vigtigt at finde forskellen, før man begynder at ændre indstillinger.

I denne guide gennemgår vi fem enkle kontroller med Windows PowerShell og almindelige Windows-netværksværktøjer.

Målet er ikke at løse alle netværksproblemer med fem kommandoer. Målet er at indsamle de rigtige oplysninger og finde et fornuftigt sted at begynde.

1. Kontrollér computerens IP-konfiguration

Når en computer mister netværksforbindelsen, er IP-konfigurationen et godt udgangspunkt.

Åbn Windows PowerShell, og kør:

Get-NetIPConfiguration

Kommandoen viser blandt andet netværksadaptere, IP-adresser, standardgateway og DNS-servere.

Du kan også bruge:

ipconfig /all

Her får du flere oplysninger om adapterne og deres aktuelle konfiguration.

Kontrollér især:

Om den aktive adapter har en gyldig IP-adresse.
Om adressen passer til virksomhedens netværk.
Om den forventede standardgateway er angivet.
Om de korrekte DNS-servere bruges.
Om computeren har forbindelse til det rigtige netværk.

En IPv4-adresse i området 169.254.x.x kan være tegn på, at computeren ikke har fået en forventet adresse fra DHCP.

Det er dog ikke i sig selv bevis på, at DHCP-serveren er defekt.

Problemet kan også ligge i netværksforbindelsen, adapteren eller den lokale konfiguration.

2. Undersøg DNS-opslag

DNS oversætter domænenavne til de IP-adresser, som systemer bruger til at kommunikere.

Hvis DNS ikke fungerer korrekt, kan brugeren opleve, at hjemmesider eller tjenester ikke kan åbnes.

Prøv:

Resolve-DnsName example.com

Kommandoen forsøger at finde DNS-oplysninger for domænet.

Du kan sammenligne med:

nslookup example.com

Bemærk, at de to værktøjer ikke nødvendigvis bruger helt samme opslagsteknik.

nslookup kan eksempelvis hjælpe med at teste svar fra en DNS-server uden at bruge Windows-klientens normale DNS-cache.

Hvad skal du kigge efter?

Hvis opslaget lykkes, ved du, at DNS-serveren har returneret et svar.

Hvis det mislykkes, bør du undersøge DNS-konfigurationen, serverens tilgængelighed og eventuelle netværksbegrænsninger.

Et vellykket DNS-opslag betyder ikke automatisk, at selve tjenesten fungerer.

Det fortæller kun noget om navneopslaget.

3. Test forbindelsen til en bestemt tjeneste

En almindelig fejl er at antage, at et netværksproblem skyldes DNS, selvom problemet faktisk handler om forbindelsen til en bestemt port.

Windows PowerShell har en nyttig kommando til TCP-test:

Test-NetConnection example.com -Port 443

Port 443 bruges almindeligvis til HTTPS.

Resultatet indeholder blandt andet feltet:

TcpTestSucceeded

Hvis værdien er True, er TCP-forbindelsen til den angivne port lykkedes.

Hvis værdien er False, kan forbindelsen ikke etableres gennem den testede netværksvej.

Det kan blandt andet skyldes:

Firewallregler.
Manglende netværksforbindelse.
Routingproblemer.
En tjeneste, der ikke lytter på porten.
Andre begrænsninger på forbindelsen.

En vellykket TCP-test beviser ikke, at hele applikationen fungerer korrekt.

Den viser kun, at forbindelsen til den testede port kunne oprettes.

4. Kontrollér om problemet gælder flere enheder

En enkelt computer uden adgang til et system kan have et lokalt problem.

Hvis flere medarbejdere oplever det samme på samme tid, bør undersøgelsen også omfatte fælles netværkskomponenter.

Begynd med at sammenligne nogle enkle oplysninger.

Kontrol	Computer A	Computer B
Netværksforbindelse	Fungerer	Fungerer ikke
IP-konfiguration	Gyldig	Skal undersøges
DNS-opslag	Lykkes	Fejler
TCP-test	Lykkes	Fejler

Tabellen er et eksempel på, hvordan observationer kan dokumenteres, ikke et faktisk testresultat.

Det kan være nyttigt at undersøge, om computerne bruger samme netværk, DNS-servere og adgang til den berørte tjeneste.

På den måde kan man hurtigere afgøre, om problemet sandsynligvis er lokalt eller fælles.

Husk også, at to computere med samme symptomer ikke nødvendigvis har samme fejl.

5. Dokumentér fejlen, før du ændrer noget

Det er nemt at blive utålmodig under fejlfinding.

Man ændrer DNS-serveren, genstarter en adapter og justerer en firewallregel.

Pludselig virker forbindelsen igen.

Men hvilken ændring løste problemet?

Hvis ingen ved det, bliver det vanskeligere at håndtere samme fejl næste gang.

En enkel fejlrapport kan gøre en stor forskel.

Brug eksempelvis denne struktur:

Fejl: Intern tjeneste kan ikke åbnes

Berørt system: Windows-computer
Berørte brugere: 3 medarbejdere

Symptom:
Applikationen kan ikke oprette forbindelse.

Udførte kontroller:
- IP-konfiguration gennemgået
- DNS-opslag testet
- TCP-forbindelse undersøgt

Observation:
DNS-opslag lykkes.
TCP-test til den relevante port fejler.

Næste skridt:
Undersøg netværksvej, firewall og tjenestens status.

Eksemplet viser en dokumentationsmetode og beskriver ikke en virkelig hændelse.

Det er også vigtigt at undgå at dele adgangskoder, private IP-oplysninger, persondata eller følsomme systemdetaljer i offentlige fejlrapporter.

Hvorfor ikke bare rydde DNS-cachen med det samme?

Du har måske set denne kommando:

ipconfig /flushdns

Den rydder Windows-klientens DNS-resolvercache.

Det kan være relevant ved bestemte problemer med cachede DNS-oplysninger.

Men kommandoen bør ikke være det automatiske første skridt ved enhver netværksfejl.

Hvis den samme fejl skyldes en forkert DNS-server, en firewallregel eller en utilgængelig tjeneste, løser en tom cache ikke nødvendigvis problemet.

Undersøg først symptomerne.

Brug derefter den handling, som passer til den sandsynlige årsag.

IT-support handler også om reproducerbare løsninger

For udviklere og IT-teknikere er en god fejlbeskrivelse ofte lige så nyttig som selve værktøjet.

Når kontrollerne bliver udført systematisk, er det nemmere at sammenligne resultater, finde mønstre og forklare næste skridt.

Det er især værdifuldt på arbejdspladser, hvor flere personer håndterer den daglige IT-drift.

En tekniker skal kunne overtage en sag uden at begynde helt forfra.

Derfor bør en supportproces ikke kun beskrive, at et problem er løst.

Den bør også forklare, hvad der blev undersøgt, og hvad løsningen byggede på.

IT Support Kolding og lokal teknisk hjælp

Virksomheder i Kolding kan have brug for assistance til både netværksproblemer, arbejdscomputere, Microsoft 365 og den daglige IT-drift.

HOUSE4IT A/S er en IT-virksomhed med adresse i Kolding, som arbejder med support og teknisk rådgivning til erhverv.

Der findes mere information om virksomhedens IT-løsninger på HOUSE4ITs officielle hjemmeside.

Uanset hvilken IT-partner en virksomhed benytter, er systematisk fejlfinding og tydelig dokumentation vigtige dele af et velfungerende supportarbejde.

En sidste teknisk pointe

PowerShell kan hjælpe med at vise, hvad der sker på en Windows-computer.

Men en kommando fortæller ikke altid hele historien.

Et vellykket DNS-opslag garanterer ikke adgang til tjenesten. En mislykket TCP-test identificerer ikke automatisk fejlkilden. Og en fungerende netværksforbindelse betyder ikke, at alle programmer virker.

Det er derfor bedst at kombinere tekniske kontroller med oplysninger fra de medarbejdere, som oplever problemet.

Start med symptomet.

Undersøg én ting ad gangen.

Dokumentér resultatet.

Og ændr først indstillingerne, når du har en god grund til det.

Redaktionel note: Denne vejledning er udarbejdet med AI-assistance. Eksemplerne er generelle og bør vurderes i forhold til virksomhedens eget IT-miljø.

DEV Community: HOUSE4IT A/S