Learn PowerShell - Network Configuration

#Introduction

In episode 20 you made sure machines are always updated and secure. But one thing makes all that pointless: if a machine isn't properly connected to the network, patches can't be downloaded, monitoring doesn't reach the center, and users can't work. The network is the lifeblood of infrastructure — and "the internet is down" complaints always end up on the administrator's desk.

This episode is your networking toolbox. We won't cover protocols from scratch, but how PowerShell manipulates the entire Windows networking stack: adapters, IP addresses, DNS, and the full suite of troubleshooting commands. What's interesting is that almost every cmdlet in this episode follows a pattern you already know — Get to read, New to create, Set to change, Remove to delete. The difference is that the object being managed this time is "the network" itself.

#Getting to Know Network Adapters

#Reading Adapter Status

All Windows network configuration centers on adapters — physical cards (Ethernet) and virtual ones (Wi-Fi, VPN, Hyper-V). The starting point of every networking task is Get-NetAdapter:

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed

Note the Status column: Up means the adapter is active and connected, Down means it's off. This is the first check when a user reports "the network isn't working" — don't immediately blame the internet.

#Enabling and Disabling Adapters

Enable-NetAdapter and Disable-NetAdapter turn adapters on or off. Set-NetAdapter changes their properties:

Disable-NetAdapter -Name "Ethernet0" -Confirm:$false
Enable-NetAdapter -Name "Ethernet0"
 
Set-NetAdapter -Name "Ethernet0" -AdminStatus Up
Get-NetAdapter -Name "Ethernet0" | Select-Object Name, Status

#IP Configuration

#Reading IP Configuration

Get-NetIPAddress shows all IP addresses on the machine. Filter with -AddressFamily IPv4 so they don't mix with IPv6 addresses:

Get-NetIPAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias, IPAddress, PrefixLength, AddressState

#DHCP vs Static IP

There are two ways a machine gets an IP address:

DHCP mode is enabled via the interface: Set-NetIPInterface -Dhcp Enabled. Static mode is done with New-NetIPAddress or Set-NetIPAddress.

#Setting a Static IP

New-NetIPAddress -InterfaceAlias "Ethernet0" `
    -IPAddress "192.168.10.15" `
    -PrefixLength 24 `
    -DefaultGateway "192.168.10.1"

-PrefixLength 24 means the subnet mask 255.255.255.0. To change an existing IP, remove the old one then create a new one:

Remove-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress "192.168.10.15" -Confirm:$false
 
New-NetIPAddress -InterfaceAlias "Ethernet0" `
    -IPAddress "192.168.10.20" `
    -PrefixLength 24 `
    -DefaultGateway "192.168.10.1"

If you want to go back to DHCP mode (releasing the static IP and accepting an IP from the DHCP server):

Remove-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress "192.168.10.20" -Confirm:$false
Set-NetIPInterface -InterfaceAlias "Ethernet0" -Dhcp Enabled

#DNS Client Configuration

#Reading and Setting DNS Servers

IP addresses tell you where other machines are, but users type names — and names are translated to IPs by DNS. The Windows DNS client manages the servers used for that translation:

Get-DnsClientServerAddress -InterfaceAlias "Ethernet0" -AddressFamily IPv4
 
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses ("192.168.10.5", "8.8.8.8")

Note the use of parentheses with -ServerAddresses — PowerShell treats it as an array, so two DNS servers are accepted at once. Set-DnsClientServerAddress is the PowerShell version of the DNS configuration window in the GUI, without clicks.

#Clearing the DNS Cache

When DNS resolution changes (for example a service's IP is moved), the local DNS cache can hold old answers and cause connections to fail. Clear-DnsClientCache empties it:

Clear-DnsClientCache

A good habit: clear the cache before testing newly changed resolution — otherwise test results can mislead you because they still use old answers.

#Network Troubleshooting

This is the part most used in the field. When everything seems wrong, you don't guess — you check in layers.

#Test-Connection: Basic Ping

Test-Connection is the ping implementation:

Test-Connection -ComputerName "192.168.10.1" -Count 4
 
Test-Connection -ComputerName "8.8.8.8" -Count 4 -Quiet

-Quiet returns True or False — perfect for use in an if condition of a monitoring script. If ping to the gateway fails but ping to another IP succeeds, the problem is on the local path, not the internet.

#Test-NetConnection: Far More Powerful than Ping

Many servers block ping (ICMP) but still accept connections. Test-NetConnection doesn't just ping — it also tests TCP ports, which is far more relevant for real services:

Test-NetConnection -ComputerName "www.example.com" -Port 443
 
Test-NetConnection -ComputerName "192.168.10.30" -Port 3389

The second command tests whether that machine's RDP port is open — diagnosing "my RDP can't connect" in one line.

#Traceroute and Resolve-DnsName

To see the path packets take to a destination, Test-NetConnection has the -TraceRoute parameter (the Windows version of tracert):

Test-NetConnection -ComputerName "8.8.8.8" -TraceRoute

And to check name-to-IP translation — the first question of any DNS resolution problem:

Resolve-DnsName -Name "www.example.com"
 
Resolve-DnsName -Name "www.example.com" -Server "8.8.8.8"

The second line forces a query to a specific DNS server — useful for comparing internal vs public DNS answers. Resolve-DnsName replaces the aging nslookup and produces structured objects, not raw text.

#Best Practices

1. Read before changing. Always start from Get-NetAdapter, Get-NetIPAddress, and Get-DnsClientServerAddress. Setting configuration without reading the current state is a blind action.
2. Document changes. Save the old configuration to a file before Set-*. When something breaks, you know exactly what values to restore.
3. Test after changing. After setting IP or DNS, immediately verify with Test-Connection and Resolve-DnsName. Don't leave before proving the connection works.
4. Be careful with remote machines. IP or DNS changes sever active sessions. Always provide a recovery path: physical console, IPMI, or a scheduled task that restores the configuration.

#Conclusion

In this episode 21 you've completed your networking toolbox: reading and managing adapters (Get-NetAdapter, Set-NetAdapter, Enable-NetAdapter, Disable-NetAdapter), IP configuration (Get-NetIPAddress, New-NetIPAddress, Set-NetIPAddress, Remove-NetIPAddress) along with DHCP and static modes, DNS clients (Get-DnsClientServerAddress, Set-DnsClientServerAddress, Clear-DnsClientCache), and layered troubleshooting with Test-Connection, Test-NetConnection for TCP ports, traceroute, and Resolve-DnsName.

Key takeaways:

• Adapters are the starting point — check Get-NetAdapter before guessing problems elsewhere.
• Test-NetConnection -Port tests real services, not just ping.
• Diagnosis order: physical path, DNS resolution, then application ports.
• Save the old configuration and provide a recovery path before resetting a remote network.

You can now configure and diagnose networks from the console. But as your scripts grow in number and complexity, an increasingly urgent question arises: how do you write scripts that are truly production-worthy? In the next episode, episode 22, we'll cover Script Best Practices & Standards: code organization, naming conventions, comment-based help, mature error handling, pipeline performance, and credential security. See you there!