A Windows VPS arrives with a virtual network adapter attached to the provider’s infrastructure, and by default that adapter pulls its address from DHCP. For a server that runs IIS, SQL Server, or RDP, that default works, but a deliberately configured network stack — a stable IP, predictable DNS servers, and a verified default route — makes administration safer, debugging faster, and outage recovery simpler.
Network behavior differs noticeably between providers: some hand out a single vNIC with one IP, others support multiple vNICs, extra IPv6 blocks, or bandwidth caps on the virtual switch. Compare Windows VPS providers on our comparison table before you commit, so the configuration steps below match what your host actually offers.
Inspect the Current Network Configuration
Before changing anything, capture the current state. On Windows Server 2019 and later, the NetTCPIP module gives you the full picture in four commands:
Get-NetIPConfiguration
Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed
Write down the interface alias (usually Ethernet or Ethernet Instance 0), the current IP, the gateway, and the DNS servers. On a provider network, the gateway is almost always the first usable address in the subnet, and the DNS servers are the provider’s resolvers — do not invent your own gateway or you will lose connectivity the moment you apply the static configuration.
Set a Static IP Address with PowerShell
With the values captured, assign the static address and DNS servers. The provider’s control panel normally shows the exact IP, subnet mask, and gateway allocated to the instance; use those numbers verbatim:
New-NetIPAddress -InterfaceAlias "Ethernet" `
-IPAddress 203.0.113.10 -PrefixLength 24 -DefaultGateway 203.0.113.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" `
-ServerAddresses ("1.1.1.1","8.8.8.8")
You can achieve the same result through Network Settings > Change adapter options in Server Manager, but the cmdlets are reproducible and safe to run inside a script. The critical operational rule: never close your RDP session until you have verified connectivity from a second session. A wrong gateway or prefix length drops the connection instantly, and if the provider’s console offers no out-of-band access you can lock yourself out entirely.
Verify DNS Resolution and Connectivity
After applying the settings, confirm every layer of the stack — interface, route, DNS, and reachability:
Test-NetConnection 203.0.113.1 -Port 3389 # gateway reachable?
Resolve-DnsName windows-vps.org # DNS resolves?
Get-NetRoute -DestinationPrefix "0.0.0.0/0" # default route present?
Test-NetConnection doubles as a firewall probe, which makes it useful for verifying that RDP (3389) and your web bindings are reachable after a network change. If resolution fails, check the DNS server list first — a stray 127.0.0.1 entry from a local DNS service is a common cause of “name not resolved” on freshly configured VPS instances.
IPv6 Considerations on a VPS
Many providers assign an IPv6 prefix alongside IPv4, and Windows enables IPv6 by default. That is usually fine, but it creates two failure modes: applications that bind only to :: may answer on IPv6 while your monitoring checks IPv4, and some older RDP clients prefer the IPv4 address when both exist. If you do not use IPv6, disable it cleanly rather than leaving a half-configured stack:
Get-NetIPAddress -AddressFamily IPv6 | Format-Table InterfaceAlias, IPAddress
Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6
If you keep IPv6, configure the DNS servers for it explicitly (Set-DnsClientServerAddress -AddressFamily IPv6) and add firewall rules for the IPv6 addresses you actually use. A VPS with a misconfigured IPv6 stack will intermittently fail connections that resolve to AAAA records.
NIC Teaming on a VPS: When It Helps and When It Does Not
NIC teaming combines multiple physical adapters into one logical interface for redundancy and throughput. On a VPS this only makes sense if the provider exposes more than one virtual NIC backed by distinct queues or bandwidth allocations — otherwise you are teaming two virtual adapters that share the same physical uplink, which adds complexity without adding capacity. Check your plan: single-vNIC plans (the majority) should skip teaming entirely.
On a provider that supports two vNICs, create the team with:
New-NetLbfoTeam -Name "Team1" `
-TeamMembers "Ethernet","Ethernet 2" `
-TeamingMode SwitchIndependent `
-LoadBalancingAlgorithm Dynamic
Get-NetLbfoTeam | Format-List Name, Status
Apply the static IP to the team interface afterward, and test failover by disabling one member adapter while a ping runs. If the provider’s virtual switch does not support LACP, SwitchIndependent mode is the only safe choice — static teaming against a switch that expects LACP will black-hole the whole interface.
Apply Changes Safely and Roll Back
Network changes on a remote server should always have a rollback path. Keep the original DHCP values in a comment block at the top of your configuration script, and know the one-liner that returns the adapter to DHCP:
Set-NetIPInterface -InterfaceAlias "Ethernet" -Dhcp Enabled
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses
Schedule risky changes in a maintenance window, keep a second RDP session or the provider’s web console open as a lifeline, and test from a different network (for example, a phone on LTE) so you are not testing connectivity from the very path you might have broken.
Summary
A deliberate network configuration — static IP, explicit DNS, verified routes, and (only where the provider supports it) NIC teaming — removes a whole class of intermittent failures from Windows VPS administration. Capture the current state, apply changes with the cmdlets above, verify every layer before closing your session, and keep the DHCP rollback one-liner handy. To size a host with the vNIC layout and bandwidth your plan needs, see the full specs and pricing on the Windows VPS comparison table.
InterServer’s Windows VPS plans include dedicated IPs and unmetered bandwidth on a stable network — try InterServer Windows VPS for one cent using promo code TRYINTERSERVER on the first month.



