M14: Advanced Networking

Master advanced Windows Server networking features including NIC Teaming, Software Defined Networking, and network security technologies.

What You'll Learn

  • NIC Teaming and load balancing
  • DHCP failover and DNS policies
  • VPN types and remote access
  • Network Policy Server (RADIUS)
  • IPAM and network management

Prerequisites

  • Windows Server fundamentals
  • TCP/IP networking basics
  • Hyper-V concepts (M04)
  • DNS and DHCP (M08-M09)
Enterprise Reality: Advanced networking skills are critical for building resilient, high-performance datacenter infrastructure with proper segmentation and security.
Advanced features that scale Windows networkingNIC Teamingmulti-NIC bundleDNS Policiesconditional answersIPAMcentralized DHCP+DNS+IPNPS / RADIUSVPN + Wi-Fi authDirectAccessseamless VPNWindows Firewall+ IPsec10 enterprise features in this moduleEach solves a real production problem you will see in the fieldBuilt on top of the basic networking you already know

NIC Teaming

Combine multiple network adapters for bandwidth aggregation and failover.

Teaming Modes

  • Switch Independent: No switch config needed
  • Static Teaming: Manual switch configuration
  • LACP: Dynamic link aggregation (802.3ad)

Load Balancing Algorithms

  • Address Hash: Source/dest MAC/IP
  • Hyper-V Port: VM-based distribution
  • Dynamic: Adaptive load balancing

NIC Teaming bonds two or more physical adapters into a single logical interface, giving you both bandwidth aggregation and automatic failover if a link drops.

# Bond two adapters into a Switch Independent team with Dynamic load balancing PS C:\> New-NetLbfoTeam -Name "DataTeam" -TeamMembers "Ethernet1", "Ethernet2" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic
# Expected output: Name Members TeamingMode Status ---- ------- ----------- ------ DataTeam {Ethernet1, Ethernet2} SwitchIndependent Up

Once the team is created, you can assign VLANs to it so a single team carries traffic for multiple network segments.

# Add a VLAN interface to the team for network segmentation PS C:\> Add-NetLbfoTeamNic -Team "DataTeam" -VlanID 100 -Name "DataTeam-VLAN100"
# Expected output: Name Team VlanID Primary ---- ---- ------ ------- DataTeam-VLAN100 DataTeam 100 False
NIC Teaming: bundle 2+ NICs into one logical NICLogical NIC10.0.0.10 / 2 GbpsNIC 11 GbpsNIC 21 GbpsNIC 3standbyLoad balancespread traffic across active NICsFailoverNIC dies, traffic shifts to others, no downtime

NIC Teaming Deep Dive

Understanding teaming modes and algorithms is critical for choosing the right configuration.

Switch Independent

  • No switch configuration required
  • Members can connect to different switches
  • Active/Standby or Active/Active modes
  • Best for: Simple failover, cross-switch redundancy

Switch Dependent (Static)

  • All members must connect to same switch
  • Switch must be configured for teaming
  • Manual port channel configuration
  • Best for: Controlled environments

LACP (802.3ad)

  • Dynamic link aggregation protocol
  • Switch and server negotiate automatically
  • Switch must support LACP
  • Detects misconfiguration automatically
  • Best for: Enterprise production environments

Hyper-V Port Algorithm

  • Assigns VMs to specific team members
  • VM traffic stays on assigned adapter
  • Best for Hyper-V hosts
  • Predictable traffic distribution
Switch Independent + LACP + Address HashTeaming Deep Dive

NIC Teaming Deep Dive, Configuration

LACP teams require matching configuration on both the server and the physical switch. The HyperVPort algorithm is ideal when the server hosts virtual machines.

# Create a four-NIC LACP team optimized for Hyper-V workloads PS C:\> New-NetLbfoTeam -Name "ProdTeam" -TeamMembers "NIC1", "NIC2", "NIC3", "NIC4" -TeamingMode LACP -LoadBalancingAlgorithm HyperVPort
# Expected output: Name Members TeamingMode Status ---- ------- ----------- ------ ProdTeam {NIC1, NIC2, NIC3, NIC4} LACP Up

After creating a team, verify its configuration and check that all members are active and healthy.

# Verify the team settings including mode and algorithm PS C:\> Get-NetLbfoTeam | Format-List Name, TeamingMode, LoadBalancingAlgorithm, Status
# Expected output: Name : ProdTeam TeamingMode : LACP LoadBalancingAlgorithm : HyperVPort Status : Up

Checking individual member status confirms each physical NIC is participating and shows its current role in the team.

# List each member adapter and its operational state PS C:\> Get-NetLbfoTeamMember -Team "ProdTeam"
# Expected output: Name Team AdministrativeMode OperationalStatus ---- ---- ------------------ ----------------- NIC1 ProdTeam Active Up NIC2 ProdTeam Active Up NIC3 ProdTeam Active Up NIC4 ProdTeam Active Up
Switch Independent + LACP + Address HashTeaming Deep Dive

DHCP Failover

DHCP failover provides high availability for DHCP services without requiring a cluster.

Hot Standby Mode

  • Primary server handles all requests
  • Standby takes over if primary fails
  • Standby reserves a % of addresses
  • Best for: Hub-and-spoke topologies
  • Simpler to configure

Load Balance Mode

  • Both servers actively serve requests
  • Configurable load distribution ratio
  • Default: 50/50 split
  • Best for: Single-site redundancy
  • Better resource utilization

Load Balance mode splits the address pool evenly between two DHCP servers so both actively serve clients. The shared secret authenticates replication traffic between the partners.

# Create a 50/50 load-balanced failover relationship for the 10.0.1.0 scope PS C:\> Add-DhcpServerv4Failover -Name "DHCP-Failover" -PartnerServer "DHCP02.hexworth.local" -ScopeId "10.0.1.0" -LoadBalancePercent 50 -SharedSecret "P@ssw0rd123" -MaxClientLeadTime "01:00:00"
# Expected output: Name ScopeId PartnerServer Mode Percent ---- ------- ------------- ---- ------- DHCP-Failover 10.0.1.0 DHCP02.hexworth.local LoadBalance 50

Hot Standby mode designates one server as active and the other as a reserve. The standby only takes over when the active server becomes unreachable.

# Create a Hot Standby failover with 10% of addresses reserved for standby PS C:\> Add-DhcpServerv4Failover -Name "DHCP-HotStandby" -PartnerServer "DHCP02.hexworth.local" -ScopeId "10.0.2.0" -ServerRole Active -ReservePercent 10
# Expected output: Name ScopeId PartnerServer Mode Reserve% ---- ------- ------------- ---- -------- DHCP-HotStandby 10.0.2.0 DHCP02.hexworth.local HotStandby 10
Key Concept: The Maximum Client Lead Time (MCLT) defines how long a server waits before assuming its partner has failed. Default is 1 hour.
Two DHCP servers share one scopeDHCP01 (primary)scope 10.0.0.0/2452% loadlease syncDHCP02 (partner)same scope48% loadTwo modes:Load Balanceboth active, configurable split (default 50/50)Hot Standbyprimary serves all, partner takes over on failureAdd-DhcpServerv4Failover -Name "Corp" -ScopeId 10.0.0.0 ...

DNS Policies

DNS policies enable advanced query handling based on client location, time of day, or query type.

Policy Types

  • Query Resolution: Control how queries are answered
  • Zone Transfer: Control which servers receive transfers
  • Recursion: Control forwarding behavior

Policy Criteria

  • Client subnet (source IP range)
  • Query type (A, AAAA, MX, etc.)
  • Time of day
  • Transport protocol (TCP/UDP)
  • Server interface
Geo + load + time-of-day rulesDNS Policies

DNS Policies, Configuration

Before creating DNS policies, you must define client subnets so the DNS server can identify where queries originate from.

# Define the headquarters subnet so DNS can identify HQ clients PS C:\> Add-DnsServerClientSubnet -Name "HeadquartersSubnet" -IPv4Subnet "10.0.1.0/24"
# Expected output: Name IPv4Subnet IPv6Subnet ---- ---------- ---------- HeadquartersSubnet {10.0.1.0/24}
# Define the branch office subnet for location-based resolution PS C:\> Add-DnsServerClientSubnet -Name "BranchSubnet" -IPv4Subnet "10.0.2.0/24"
Geo + load + time-of-day rulesDNS Policies

DNS Policies, Configuration (cont.)

Zone scopes let a single DNS zone serve different records depending on which policy matches the incoming query.

# Create a separate zone scope for branch office DNS answers PS C:\> Add-DnsServerZoneScope -ZoneName "hexworth.local" -Name "BranchScope"
# Expected output: ZoneName ZoneScope FileName -------- --------- -------- hexworth.local BranchScope BranchScope.dns

Add a resource record to the branch scope so branch clients resolve to their local application server instead of the HQ server.

# Add an A record for "app" that resolves to the branch server IP inside BranchScope PS C:\> Add-DnsServerResourceRecord -ZoneName "hexworth.local" -A -Name "app" -IPv4Address "10.0.2.100" -ZoneScope "BranchScope"

The resolution policy ties everything together: when a client from the branch subnet queries, DNS returns the branch scope answer.

# Route queries from BranchSubnet to the BranchScope zone answers PS C:\> Add-DnsServerQueryResolutionPolicy -Name "BranchPolicy" -Action ALLOW -ClientSubnet "EQ,BranchSubnet" -ZoneScope "BranchScope,1" -ZoneName "hexworth.local"
# Expected output: Name Action ClientSubnet ZoneScope ZoneName ---- ------ ------------ --------- -------- BranchPolicy ALLOW EQ,BranchSubnet BranchScope,1 hexworth.local
Geo + load + time-of-day rulesDNS Policies

Split-Brain DNS

Split-brain DNS serves different answers for the same hostname based on whether the client is internal or external.

How It Works

  • Same DNS name resolves to different IPs
  • Internal clients get private IP addresses
  • External clients get public IP addresses
  • Implemented with DNS policies in Server 2016+
  • Previously required separate DNS servers

Use Cases

  • Web applications with internal/external access
  • Exchange Autodiscover
  • SharePoint with external publishing
  • Any service with different internal vs external paths
Internal name resolves differently inside vs outSplit-Brain DNS

Split-Brain DNS, Configuration

The default zone scope already holds the internal record (app.hexworth.local = 10.0.1.50). Create an external scope to hold the public-facing answer.

# Create a zone scope to hold external-facing DNS records PS C:\> Add-DnsServerZoneScope -ZoneName "hexworth.local" -Name "ExternalScope"
# Expected output: ZoneName ZoneScope FileName -------- --------- -------- hexworth.local ExternalScope ExternalScope.dns

Add the same hostname to the external scope, but pointing to the public IP address so external clients reach the edge server.

# Add the public IP for "app" into the ExternalScope PS C:\> Add-DnsServerResourceRecord -ZoneName "hexworth.local" -A -Name "app" -IPv4Address "203.0.113.50" -ZoneScope "ExternalScope"

The policy matches any query that does NOT come from the internal subnet and directs it to the external scope, achieving split-brain resolution from a single DNS server.

# Send non-internal clients to ExternalScope for split-brain resolution PS C:\> Add-DnsServerQueryResolutionPolicy -Name "SplitBrainExternal" -Action ALLOW -ClientSubnet "NE,InternalSubnet" -ZoneScope "ExternalScope,1" -ZoneName "hexworth.local"
# Expected output: Name Action ClientSubnet ZoneScope ZoneName ---- ------ ------------ --------- -------- SplitBrainExternal ALLOW NE,InternalSubnet ExternalScope,1 hexworth.local
Internal name resolves differently inside vs outSplit-Brain DNS

DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic signatures to DNS records to prevent spoofing and tampering.

DNSSEC Components

  • RRSIG: Digital signature for DNS records
  • DNSKEY: Public key for verifying signatures
  • DS: Delegation Signer (parent zone trust)
  • NSEC/NSEC3: Proof of non-existence
  • KSK: Key Signing Key (signs DNSKEY)
  • ZSK: Zone Signing Key (signs records)

DNSSEC Benefits

  • Prevents DNS cache poisoning
  • Validates DNS response authenticity
  • Chain of trust from root to zone
  • Required by some government policies
  • Supported in Server 2012+
Sign zones, verify chain of trust, DNSKEY+RRSIGDNSSEC

DNSSEC (DNS Security Extensions), Configuration

Signing a zone generates the KSK and ZSK automatically, then creates RRSIG records for every existing DNS record in the zone.

# Sign the zone with default DNSSEC parameters (auto-generates KSK and ZSK) PS C:\> Invoke-DnsServerZoneSign -ZoneName "hexworth.local" -SignWithDefault
# Expected output: ZoneName IsSigned DenialOfExistence IsKeyMasterServer -------- -------- ----------------- ----------------- hexworth.local True NSec3 True

Resolving servers need trust anchors to validate signatures. The DS record digest ties the child zone key to the parent zone trust chain.

# Distribute the trust anchor digest to resolving DNS servers PS C:\> Add-DnsServerTrustAnchor -Name "hexworth.local" -CryptoAlgorithm RsaSha256 -KeyTag 12345 -Digest "ABCDEF..." -DigestType Sha256

After signing, verify the zone's DNSSEC settings to confirm it is actively signed and which algorithms are in use.

# Check the current DNSSEC signing status and key configuration PS C:\> Get-DnsServerDnsSecZoneSetting -ZoneName "hexworth.local"
# Expected output: ZoneName : hexworth.local IsSigned : True DenialOfExistence : NSec3 NSec3HashAlgorithm : RsaSha256 IsKeyMasterServer : True KeyMasterServer : DC01.hexworth.local
Caution: DNSSEC increases DNS response sizes and requires key management. Plan key rollover procedures before deploying in production.
Sign zones, verify chain of trust, DNSKEY+RRSIGDNSSEC

IPAM (IP Address Management)

IPAM provides centralized management of the IP address space across multiple DHCP and DNS servers.

IPAM Features

  • Centralized IP address tracking
  • DHCP and DNS server management
  • IP address utilization monitoring
  • IP address auditing and tracking
  • Multi-server management console

IPAM Components

  • IPAM Server: Central management server
  • IPAM Database: WID or SQL Server
  • Managed Servers: DHCP/DNS/DC servers
  • IPAM Client: Server Manager or RSAT
IP Address Management single pane across DHCP+DNSIPAM

IPAM (IP Address Management), Configuration

IPAM requires its Windows feature to be installed first. The management tools include both the Server Manager snap-in and PowerShell module.

# Install the IPAM role and its management tools PS C:\> Install-WindowsFeature -Name IPAM -IncludeManagementTools
# Expected output: Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- True No Success {IP Address Management (IPAM) Server}

Provisioning initializes the IPAM database. The WID (Windows Internal Database) option is simpler for smaller environments.

# Initialize the IPAM database using Windows Internal Database PS C:\> Invoke-IpamServerProvisioning -WidSchemaPath "C:\Windows\System32\ipam\ipamschema.mdf"
IP Address Management single pane across DHCP+DNSIPAM

IPAM (IP Address Management), Configuration (cont.)

After provisioning, discover DHCP, DNS, and domain controller servers across the domain so IPAM can begin tracking their address spaces.

# Scan the domain to discover all DHCP, DNS, and DC servers PS C:\> Invoke-IpamServerDiscovery -Domain "hexworth.local"
# Expected output: ServerName ServerType ManageabilityStatus ---------- ---------- ------------------- DC01.hexworth.local DC, DNS Managed DHCP01.hexworth.local DHCP Managed DHCP02.hexworth.local DHCP Managed

Once servers are discovered, query subnet utilization to identify address pools nearing exhaustion before they become a problem.

# Check IP address utilization across all managed subnets PS C:\> Get-IpamSubnet | Select-Object NetworkId, PercentageUtilized, TotalAddresses
# Expected output: NetworkId PercentageUtilized TotalAddresses --------- ------------------ -------------- 10.0.1.0/24 72 254 10.0.2.0/24 45 254 10.0.3.0/24 18 254
IP Address Management single pane across DHCP+DNSIPAM

Network Policy Server (NPS/RADIUS)

NPS is Microsoft's implementation of RADIUS for centralized network access authentication and authorization.

NPS Use Cases

  • VPN Authentication: RRAS VPN server
  • WiFi (802.1X): Wireless authentication
  • Wired 802.1X: Switch port authentication
  • RADIUS Proxy: Forward to other RADIUS servers

NPS Components

  • RADIUS Clients: VPN servers, APs, switches
  • Connection Request Policies: How to handle requests
  • Network Policies: Allow/deny based on conditions
  • Accounting: Log authentication events
Auth + Authz for VPN + Wi-Fi + switchesNPS / RADIUS

Network Policy Server (NPS/RADIUS), Configuration

The Network Policy and Access Services (NPAS) role includes NPS, the RADIUS server, and its management console.

# Install the Network Policy Server role for RADIUS authentication PS C:\> Install-WindowsFeature -Name NPAS -IncludeManagementTools
# Expected output: Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- True No Success {Network Policy and Access Services}

Registering NPS in Active Directory grants the server permission to read user account dial-in properties for authentication decisions.

# Register this NPS server with Active Directory for account lookups PS C:\> netsh nps set registeredserver domain=hexworth.local server=NPS01
# Expected output: Registration of the Network Policy Server in Active Directory domain hexworth.local succeeded.

Each network device that sends authentication requests to NPS must be registered as a RADIUS client with a matching shared secret.

# Register the VPN server as a RADIUS client with a shared secret PS C:\> New-NpsRadiusClient -Name "VPN-Server" -Address "10.0.1.5" -SharedSecret "R@diusSecret123"
# Expected output: Name Address Enabled SharedSecret ---- ------- ------- ------------ VPN-Server 10.0.1.5 True ************
Auth + Authz for VPN + Wi-Fi + switchesNPS / RADIUS

VPN Types

Windows Server supports multiple VPN protocols through the RRAS (Routing and Remote Access Service) role.

VPN Protocols

  • IKEv2: Most recommended, fast reconnection
  • SSTP: Uses HTTPS (port 443), firewall-friendly
  • L2TP/IPsec: Strong encryption, widely supported
  • PPTP: Legacy, insecure - avoid in production

Choosing a Protocol

  • IKEv2: Best for mobile users (reconnect after sleep)
  • SSTP: Best when behind restrictive firewalls
  • L2TP: Compatible with most VPN clients
  • IKEv2 and SSTP require certificates
Windows VPN protocols comparedSSTPTCP 443, blends with HTTPSIKEv2UDP 500+4500, fast reconnectL2TP/IPsecUDP 1701, legacy compatPPTPDEPRECATED weak cryptoAlways On VPNdevice + user tunnels, modernChoose by:• firewall friendliness• mobile roaming need• client OS version• crypto requirements2024 default:Always On VPN

VPN Types, Configuration

The RRAS role provides both VPN and routing capabilities. Installing both roles enables the server to act as a VPN gateway with routing support.

# Install the Remote Access role with VPN and Routing sub-features PS C:\> Install-WindowsFeature -Name DirectAccess-VPN, Routing -IncludeManagementTools
# Expected output: Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- True No Success {DirectAccess and VPN (RAS), Routing}

After installing the role, configure the Remote Access service specifically for VPN connections.

# Initialize the Remote Access service in VPN mode PS C:\> Install-RemoteAccess -VpnType Vpn

The VPN address pool defines which IP addresses are handed to connecting VPN clients. Size this range based on your expected concurrent user count.

# Assign the IP address range that VPN clients will receive PS C:\> Set-RemoteAccessConfiguration -VpnAddressPool "10.0.100.1", "10.0.100.254"
# Expected output: VpnType : Vpn VpnAddressStart : 10.0.100.1 VpnAddressEnd : 10.0.100.254 VpnStatus : Running
Security: PPTP uses MS-CHAPv2 which has known vulnerabilities. Always prefer IKEv2 or SSTP for production VPN deployments.
Windows VPN protocols comparedSSTPTCP 443, blends with HTTPSIKEv2UDP 500+4500, fast reconnectL2TP/IPsecUDP 1701, legacy compatPPTPDEPRECATED weak cryptoAlways On VPNdevice + user tunnels, modernChoose by:• firewall friendliness• mobile roaming need• client OS version• crypto requirements2024 default:Always On VPN

DirectAccess

DirectAccess provides seamless, always-on remote connectivity without traditional VPN connections.

How DirectAccess Works

  • Automatic connection when outside corporate network
  • Uses IPv6 transition technologies (6to4, Teredo, IP-HTTPS)
  • Bi-directional: IT can manage remote machines
  • No user action required to connect
  • Machine certificate authentication

Requirements

  • Windows Enterprise or Education clients
  • Domain-joined computers only
  • Active Directory and Group Policy
  • Certificate infrastructure (AD CS)
  • DirectAccess server with 2 NICs (or behind NAT)
Pre-tunnel before logon (legacy)DirectAccess

DirectAccess, Configuration

DirectAccess requires the same Remote Access role as VPN. The feature name includes both capabilities in a single package.

# Install the Remote Access role that includes DirectAccess capability PS C:\> Install-WindowsFeature -Name DirectAccess-VPN -IncludeManagementTools
# Expected output: Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- True No Success {DirectAccess and VPN (RAS)}

FullInstall mode deploys DirectAccess with all components. The ConnectToAddress is the public hostname clients use to reach the DA server.

# Deploy DirectAccess with full installation using the public-facing hostname PS C:\> Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress "da.hexworth.com"

Force tunneling routes all client traffic through the corporate network, not just internal destinations. This gives IT full visibility into remote client traffic.

# Enable force tunneling so all remote traffic routes through the DA server PS C:\> Set-DAClient -ComputerName "DA-Clients" -ForceTunnel Enabled
# Expected output: ComputerName : DA-Clients ForceTunnel : Enabled OnlyRemoteComputers : Disabled
Note: DirectAccess is being superseded by Always On VPN in newer Windows deployments, which supports non-domain-joined devices and all Windows editions.
Pre-tunnel before logon (legacy)DirectAccess

BranchCache

BranchCache reduces WAN bandwidth consumption by caching content locally at branch offices.

BranchCache Modes

  • Distributed Cache: Clients share cached content peer-to-peer
  • Hosted Cache: Dedicated server stores cache at branch

Supported Content

  • SMB file shares (file servers)
  • HTTP/HTTPS content (IIS, WSUS)
  • BITS-based transfers (SCCM)

How It Works

  • First client downloads from HQ over WAN
  • Content is cached locally
  • Subsequent requests served from local cache
  • Content validated using hashes
  • Transparent to end users
Edge cache for slow WAN sitesBranchCache

BranchCache, Configuration

BranchCache must be installed as a feature on the content servers at headquarters before branch clients can start caching.

# Install the BranchCache feature on the content server PS C:\> Install-WindowsFeature -Name BranchCache -IncludeManagementTools
# Expected output: Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- True No Success {BranchCache}

In Distributed Cache mode, branch office clients share cached content peer-to-peer without needing a dedicated cache server.

# Enable BranchCache in Distributed mode for peer-to-peer caching PS C:\> Enable-BCDistributed

Individual file shares must be explicitly enabled for BranchCache. Only shares with this setting generate content hashes for branch clients.

# Turn on BranchCache hash generation for this specific share PS C:\> Set-SmbShare -Name "SharedDocs" -CachingMode BranchCache

After configuration, verify the overall BranchCache status to confirm the service is running and which mode is active.

# Display the current BranchCache service status and configuration PS C:\> Get-BCStatus
# Expected output: BranchCacheServiceStatus : Running ContentServerIsEnabled : True HostedCacheServerIsEnabled : False DistributedCachingIsEnabled : True CurrentClientMode : DistributedCache
Edge cache for slow WAN sitesBranchCache

VLANs and Network Isolation

Virtual LANs segment network traffic at Layer 2 for security and performance.

VLAN Use Cases

  • Security isolation - Separate sensitive systems
  • Broadcast containment - Reduce broadcast domains
  • Traffic management - QoS and prioritization
  • Multi-tenancy - Customer separation

Tagging a physical adapter with a VLAN ID restricts it to only that VLAN's traffic. The switch port must be configured as an access or trunk port accordingly.

# Assign VLAN 100 to a physical network adapter PS C:\> Set-NetAdapter -Name "Ethernet1" -VlanID 100
# Expected output: Name InterfaceDescription VlanID Status ---- -------------------- ------ ------ Ethernet1 Intel(R) I350 Adapter 100 Up

For Hyper-V environments, you assign VLANs at the virtual NIC level so each VM can be placed on its own network segment.

# Tag a Hyper-V VM's virtual NIC with VLAN 100 in access mode PS C:\> Set-VMNetworkAdapterVlan -VMName "WebServer" -Access -VlanId 100
# Expected output: VMName OperationMode VlanList ------ ------------- -------- WebServer Access 100
Switch Configuration: Physical switches must be configured for 802.1Q trunking to pass VLAN-tagged traffic.
L2 isolation, trunk 802.1Q tagVLANs

Software Defined Networking

SDN separates the control plane from the data plane for programmable networks.

SDN Components

  • Network Controller: Central management
  • Software Load Balancer: Layer 4 LB
  • RAS Gateway: VPN and routing
  • Datacenter Firewall: Distributed firewall

Benefits

  • Centralized network management
  • Automated provisioning
  • Micro-segmentation
  • Network virtualization

SDN virtual networks are created through the Network Controller's REST API. The properties object defines the address space and subnet structure.

# Provision a new virtual network through the SDN Network Controller PS C:\> New-NetworkControllerVirtualNetwork -ConnectionUri "https://nc.hexworth.local" -ResourceId "Production-VNet" -Properties $vnetProperties
# Expected output: ResourceId ProvisioningState ConnectionUri ---------- ----------------- ------------- Production-VNet Succeeded https://nc.hexworth.local
Guest, Voice, IoT, ManagementVLAN Use Cases

Network Virtualization (HNV)

Hyper-V Network Virtualization enables overlay networks that decouple virtual networks from the physical infrastructure.

HNV Concepts

  • Customer Address (CA): VM's virtual IP
  • Provider Address (PA): Physical host IP
  • VXLAN/NVGRE: Encapsulation protocols
  • Virtual Subnet: Isolated layer 2 network
  • Supports overlapping IP address spaces

Benefits

  • Multi-tenant isolation without VLANs
  • Workload mobility across physical hosts
  • Independent virtual network topology
  • Cross-subnet live migration
  • Managed via Network Controller

Virtual network properties are defined as a PowerShell hashtable before being sent to the Network Controller REST API. This example creates a two-tier network with web and app subnets.

# Build the virtual network properties object with two subnet tiers PS C:\> $vnetProperties = @{ AddressSpace = @{ AddressPrefixes = @("10.100.0.0/16") } Subnets = @( @{ ResourceId = "WebTier"; Properties = @{ AddressPrefix = "10.100.1.0/24" } } @{ ResourceId = "AppTier"; Properties = @{ AddressPrefix = "10.100.2.0/24" } } ) }
# Expected output (displaying the variable): Name Value ---- ----- AddressSpace {AddressPrefixes} Subnets {WebTier, AppTier}
Distributed virtualized network fabricSDN

Windows Firewall with Advanced Security

Windows Firewall provides stateful packet filtering and application-aware protection.

Rule Types

  • Inbound Rules: Control incoming connections
  • Outbound Rules: Control outgoing connections
  • Connection Security Rules: IPsec authentication

Inbound rules control what traffic is allowed to reach the server. This rule opens port 443 for HTTPS connections from any source.

# Allow inbound HTTPS traffic on TCP port 443 PS C:\> New-NetFirewallRule -DisplayName "Allow HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
# Expected output: Name DisplayName Direction Action Protocol LocalPort ---- ----------- --------- ------ -------- --------- {GUID} Allow HTTPS Inbound Allow TCP 443

Outbound rules restrict what traffic leaves the server. Blocking legacy insecure protocols like Telnet prevents accidental use of unencrypted sessions.

# Block all outbound Telnet connections on TCP port 23 PS C:\> New-NetFirewallRule -DisplayName "Block Telnet" -Direction Outbound -Protocol TCP -RemotePort 23 -Action Block
# Expected output: Name DisplayName Direction Action Protocol RemotePort ---- ----------- --------- ------ -------- ---------- {GUID} Block Telnet Outbound Block TCP 23
Hyper-V Network Virtualization NVGRE/VXLANHNV

IPsec Configuration

Internet Protocol Security provides authentication and encryption at the network layer.

IPsec Modes

  • Transport: Encrypts payload only
  • Tunnel: Encrypts entire packet (VPN)

Authentication Methods

  • Kerberos (Active Directory)
  • Certificates (PKI)
  • Pre-shared keys (testing only)

IPsec rules enforce encryption between hosts. Requiring both inbound and outbound security ensures all traffic to and from the target subnet is encrypted.

# Require IPsec encryption for all traffic to the 10.0.1.0/24 subnet PS C:\> New-NetIPsecRule -DisplayName "Encrypt DC Traffic" -InboundSecurity Require -OutboundSecurity Require -RemoteAddress "10.0.1.0/24"
# Expected output: DisplayName InboundSecurity OutboundSecurity RemoteAddress ----------- --------------- ---------------- ------------- Encrypt DC Traffic Require Require 10.0.1.0/24

Quick Mode Security Associations show active IPsec tunnels between hosts, confirming encryption is working in real time.

# List all active IPsec Quick Mode Security Associations PS C:\> Get-NetIPsecQuickModeSA
# Expected output: Name LocalEndpoint RemoteEndpoint EncryptAlgorithm AuthAlgorithm ---- ------------- -------------- ---------------- ------------- {GUID} 10.0.1.10 10.0.1.20 AES256 SHA256 {GUID} 10.0.1.10 10.0.1.30 AES256 SHA256
3 profiles, 3 rule directionsDomain profileon corp networkRDP allowedSMB allowedWinRM allowedPrivate profilehome / trustedfile sharing onnetwork discovery onPublic profilecoffee shop Wi-Fiblock inboundno discoverystrict defaultRule directionsInboundmost-restrictive, deny defaultOutboundusually allowed, but can block specific appsConnection SecurityIPsec rules layer over the firewall

Quality of Service (QoS)

QoS policies prioritize network traffic to ensure performance for critical applications.

QoS Configuration

  • DSCP Marking - Tag packets with priority values
  • Throttle Rate - Limit bandwidth consumption
  • Application-based - Target specific executables
  • Port-based - Target specific services

DSCP marking tags packets with a priority value so network switches and routers give them preferential treatment. DSCP 46 is the Expedited Forwarding class used for real-time voice.

# Tag SIP/VoIP traffic (ports 5060-5061) with DSCP 46 for priority handling PS C:\> New-NetQosPolicy -Name "VoIP Priority" -IPDstPortStart 5060 -IPDstPortEnd 5061 -DSCPAction 46 -NetworkProfile Domain
# Expected output: Name IPDstPortStart IPDstPortEnd DSCPValue NetworkProfile ---- -------------- ------------ --------- -------------- VoIP Priority 5060 5061 46 Domain

Throttle policies cap bandwidth for non-critical applications so they cannot saturate the network during business hours.

# Limit backup.exe to 100 Mbps so it does not consume all available bandwidth PS C:\> New-NetQosPolicy -Name "Backup Throttle" -AppPathNameMatchCondition "backup.exe" -ThrottleRateActionBitsPerSecond 100MB
# Expected output: Name AppPathName ThrottleRate NetworkProfile ---- ----------- ------------ -------------- Backup Throttle backup.exe 104857600 All
Program / Port / Predefined / CustomRule Types

Network Address Translation (NAT)

NAT enables private network addresses to communicate with public networks.

NAT Types

  • SNAT: Source NAT (outbound)
  • DNAT: Destination NAT (port forwarding)
  • Static NAT: 1:1 mapping
  • Dynamic NAT: Pool-based

Use Cases

  • Internet access for private networks
  • Publishing internal services
  • Lab environments
  • Container networking

Windows Server NAT translates private IPs for an entire subnet. This is commonly used with Hyper-V internal switches to give VMs internet access.

# Create a NAT network for the 192.168.100.0/24 private subnet PS C:\> New-NetNat -Name "LabNAT" -InternalIPInterfaceAddressPrefix "192.168.100.0/24"
# Expected output: Name InternalIPInterfaceAddressPrefix Active ---- ---------------------------------- ------ LabNAT 192.168.100.0/24 True

Static port mappings forward specific external ports to internal servers, allowing you to publish services behind the NAT.

# Forward external port 8080 to internal web server 192.168.100.10 on port 80 PS C:\> Add-NetNatStaticMapping -NatName "LabNAT" -Protocol TCP -ExternalIPAddress "0.0.0.0" -ExternalPort 8080 -InternalIPAddress "192.168.100.10" -InternalPort 80
# Expected output: StaticMappingID NatName Protocol ExternalPort InternalAddress InternalPort --------------- ------- -------- ------------ --------------- ------------ 0 LabNAT TCP 8080 192.168.100.10 80
Encrypt + authenticate L3 between hostsIPsec

Network Diagnostics

Troubleshoot network issues with built-in Windows tools and PowerShell cmdlets.

Diagnostic Tools

  • Test-NetConnection: Connectivity testing
  • Get-NetTCPConnection: Active connections
  • Get-NetRoute: Routing table
  • netsh trace: Packet capture

Performance Counters

  • Network Interface\Bytes/sec
  • TCPv4\Connections Established
  • Network Adapter\Packets/sec
  • RDMA Activity counters
QoS: prioritize traffic by app / port / DSCPVoIP / Teams trafficDSCP EF (46) high priorityUDP 3478-3481, app-specific QoS policyBusiness app trafficDSCP AF (24) mediumCRM, ERP, line of businessBulk trafficCS1 (8) lowbackups, file copies, OS updatesSet-NetQosPolicy + matching DSCP rules on switchesWithout QoS, big file copies starve voice calls

Network Diagnostics, Configuration

Test-NetConnection is the PowerShell replacement for telnet and ping combined. It tests both ICMP reachability and TCP port connectivity in a single command.

# Test TCP connectivity to a remote server on port 443 (HTTPS) PS C:\> Test-NetConnection -ComputerName "server.hexworth.local" -Port 443
# Expected output: ComputerName : server.hexworth.local RemoteAddress : 10.0.1.50 RemotePort : 443 TcpTestSucceeded : True PingSucceeded : True

Grouping active TCP connections by remote address quickly reveals which external hosts your server communicates with most.

# Group all established TCP connections by remote IP to find top talkers PS C:\> Get-NetTCPConnection -State Established | Group-Object RemoteAddress
# Expected output: Count Name Group ----- ---- ----- 12 10.0.1.10 {Microsoft.Management.Infrastructure.CimInstance...} 8 10.0.1.20 {Microsoft.Management.Infrastructure.CimInstance...} 3 10.0.1.30 {Microsoft.Management.Infrastructure.CimInstance...}

For deep packet analysis, netsh trace captures raw network traffic into an ETL file that can be opened in Message Analyzer or converted to pcap.

# Start a packet capture and save it to an ETL trace file PS C:\> netsh trace start capture=yes tracefile=C:\Temp\trace.etl
# Expected output: Trace configuration: ------------------------------------------------------------------- Status: Running Trace File: C:\Temp\trace.etl Append: Off Circular: Off Max Size: 250 MB
QoS: prioritize traffic by app / port / DSCPVoIP / Teams trafficDSCP EF (46) high priorityUDP 3478-3481, app-specific QoS policyBusiness app trafficDSCP AF (24) mediumCRM, ERP, line of businessBulk trafficCS1 (8) lowbackups, file copies, OS updatesSet-NetQosPolicy + matching DSCP rules on switchesWithout QoS, big file copies starve voice calls

Lab Preview

Practice advanced networking configuration through both interfaces.

GUI Lab Tasks

  • Create NIC Team
  • Configure DHCP failover
  • Create DNS policies
  • Configure firewall rules
  • Configure QoS policies
  • Set up NPS RADIUS
  • Set up NAT

PowerShell Lab Tasks

  • Create and manage NIC teams
  • Configure DHCP failover
  • Create DNS zone scopes and policies
  • Configure firewall and IPsec rules
  • Create QoS policies
  • Configure BranchCache
  • Perform network diagnostics
Start GUI Lab Start PowerShell Lab
New-NetQosPolicy by app/port + DSCP valueQoS Config
Course Home