Start typing to search across invoices, services, domains, tickets, and more...
A Windows Server that has lost network connectivity is one of the most stressful problems: Remote Desktop fails, websites go down, or the server can reach IPs but cannot resolve domain names. This guide walks through Windows Server network adapter and connectivity troubleshooting in a fixed order — adapter → IP and gateway → internet → DNS → firewall — using built-in tools such as ipconfig, ping, tracert and netsh on Windows Server 2016 / 2019 / 2022.
Open PowerShell or CMD as Administrator and check the adapter status and IP settings:
ipconfig /all
Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MacAddress -AutoSize
Check that the adapter Status is Up; that the IPv4 address, subnet mask and default gateway match your server's provisioning details; and whether you see a 169.254.x.x address (DHCP failed or the IP configuration was lost). If the adapter is disabled, enable it (use your actual adapter name, e.g. "Ethernet"):
Enable-NetAdapter -Name "Ethernet" -Confirm:$false
Restart-NetAdapter -Name "Ethernet"
If Device Manager shows a yellow warning on the adapter or no adapter at all, the driver may be missing (common with self-installed OS images). Open a ticket for driver assistance.
Ping the default gateway, a public IP and a domain name in turn to find which layer is failing:
ping 203.0.113.1
ping 8.8.8.8
ping www.microsoft.com
Gateway unreachable: most likely a wrong IP / mask / gateway or an adapter problem. Gateway OK but 8.8.8.8 unreachable: routing or upstream network. 8.8.8.8 OK but "could not find host": a DNS problem — go to Step 4.
Use tracert to see where packets stop. The -d switch skips reverse lookups for faster results:
tracert -d 8.8.8.8
route print
If the IP or gateway was changed by mistake, set the static IP again with netsh (use the actual values from your provisioning details):
netsh interface ipv4 set address name="Ethernet" static 203.0.113.10 255.255.255.0 203.0.113.1
If IPs respond but domain names do not resolve, test DNS and flush the cache:
nslookup www.microsoft.com
ipconfig /flushdns
If nslookup times out, set reliable public DNS servers on the adapter:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 8.8.8.8,1.1.1.1
Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
If everything looks right but the network still fails, or problems started after installing a VPN, proxy or "accelerator" tool, reset Winsock and the TCP/IP stack and reboot:
ipconfig /all > C:\ipconfig-backup.txt
netsh winsock reset
netsh int ip reset
Restart-Computer
If the server can reach the internet but outside clients cannot ping it or reach a port, the firewall is the usual cause. Check the firewall profiles and allow ICMP (ping) and your service ports as needed:
Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction
New-NetFirewallRule -DisplayName "Allow-ICMPv4-In" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow
New-NetFirewallRule -DisplayName "Allow-Web-80-443" -Direction Inbound -Protocol TCP -LocalPort 80,443 -Action Allow
Run ping -t <server IP> locally together with tracert to record where loss starts, and check whether the server is under attack or saturating its bandwidth (Task Manager → Performance → Ethernet).
Some networks use static IPs, so you must enter the IP, mask, gateway and DNS from your provisioning details manually. If a self-installed OS is missing the NIC driver, open a ticket.
Run tracert or MTR from that region and send the results to support so we can analyse the route.
If none of the above helps, submit a ticket to IMIDC 24/7 technical support with screenshots of ipconfig /all, ping and tracert.