NIC teaming bonds two or more physical adapters into one logical adapter for both bandwidth aggregation and fault tolerance. If an adapter, cable, or switch port fails, traffic continues on the surviving members with no session loss.

Two independent choices. Every team is defined by a teaming MODE (how the team relates to the physical switch) and a load-balancing ALGORITHM (how outbound traffic is spread across members). You set them separately.

Teaming modes. Switch Independent: the switch is unaware of the team, so members can even attach to two different switches and survive a whole-switch failure. Static (Generic Trunking, 802.3ad static): a manually configured port channel; all members must reach the same switch. LACP (802.3ad dynamic): server and switch negotiate the aggregation automatically, the enterprise standard wherever the switch supports it.

Load-balancing algorithms. Address Hash hashes the packet 5-tuple to pick a member (stateless). Dynamic is Microsoft's default and rebalances flows for best throughput. Hyper-V Port pins each VM's virtual port to one member for predictable per-VM behavior.

Active posture and the modern path. Switch Independent can hold one member as hot standby or run all members active; switch-dependent modes generally distribute across all members. Note: on Hyper-V hosts, LBFO (New-NetLbfoTeam) is deprecated in favor of Switch Embedded Teaming (SET), which builds the team into the virtual switch.

DHCP failover pairs two DHCP servers so a single server outage never stops address leasing. Both servers share the same scope and continuously synchronize lease data, so either one can answer any client. It replaced the brittle old "split scope" workaround where each server owned a separate slice of the pool.

Hot Standby (active/passive). One server is primary and serves all requests; the partner waits in reserve, holding a percentage of the pool (5% by default) to cover the window until it formally takes over. Best for a central-plus-branch topology where one site is clearly primary.

Load Balance (active/active). Both servers answer clients at the same time, splitting the load (50/50 by default, configurable). Best when two servers sit in the same site and you want both working.

The safety timers. Partners authenticate to each other with a SHARED SECRET. The MCLT (Maximum Client Lead Time) bounds how far ahead of its partner a server may extend a lease, so the partner can safely assume control without ever handing out a conflicting address. Failover is a relationship configured on the pair, not a per-server toggle.

DNS policies let one DNS server return DIFFERENT answers to the same query depending on who is asking or when. Instead of one static record per name, the server evaluates rules at query time and chooses which record set to serve.

What a policy controls. Query Resolution: return different records based on a match (the common case). Zone Transfer: restrict which secondaries may pull a zone. Recursion: enable or disable recursion per client subnet.

The match criteria. A policy fires when the query matches one or more conditions: client subnet (where the resolver sits), query type (A vs AAAA vs MX), time of day, or transport (TCP vs UDP). Criteria combine, so "AAAA queries from the branch subnet after hours" is expressible.

How it fits together. Define a CLIENT SUBNET (a named IP range), create a ZONE SCOPE (a separate record set inside the zone), add records to that scope, then bind them with a QUERY RESOLUTION POLICY that maps subnet to scope. The scope is the alternate answer; the policy is the routing rule.

Split-brain DNS (split-horizon) serves the SAME hostname with DIFFERENT IP addresses depending on whether the client is inside or outside the network. app.hexworth.com resolves to a private 10.x address for staff on the LAN and to a public address for everyone on the internet, from one authoritative zone.

Why you want it. Internal clients reach the application directly over the LAN (fast, no hairpin through the firewall), while external clients are steered to the public-facing endpoint, reverse proxy, or VPN. One name, two routes, no duplicate zones to keep in sync.

Classic use cases. Internal vs external web apps, Exchange Autodiscover, SharePoint, and any service published both inside and out. It is the standard pattern wherever the same FQDN must behave differently by client location.

How it is built. It is DNS policies applied to the location problem: define an internal and an external ZONE SCOPE, put the private record in one and the public record in the other, then write QUERY RESOLUTION POLICIES that map the internal client subnet to the internal scope and everyone else to the external scope.

Plain DNS has no authenticity: a client cannot tell a genuine answer from a forged one, which is what cache-poisoning attacks exploit. DNSSEC adds cryptographic SIGNATURES so a resolver can verify that a record really came from the zone owner and was not tampered with in transit. It provides origin authentication and integrity, not confidentiality (answers are still public).

The record types. RRSIG is the signature over a record set. DNSKEY holds the public keys used to verify RRSIGs. DS (Delegation Signer) lives in the PARENT zone and fingerprints the child's key, linking the two. NSEC/NSEC3 provide authenticated "this name does not exist" answers without leaking the whole zone.

KSK and ZSK. The Key Signing Key signs the DNSKEY set (the anchor); the Zone Signing Key signs the actual records. Splitting them lets you rotate the busy ZSK often while the KSK, which the parent's DS points at, stays stable.

The chain of trust. A resolver validates upward: the record's RRSIG verifies against the zone's DNSKEY, that key is vouched for by the parent's DS, and so on up to the trust anchor (the root). Any broken link fails validation. Sign the zone, then publish the DS to the parent and a trust anchor to your resolvers.

IPAM is the single console for your entire IP estate. Instead of tracking subnets in a spreadsheet and managing each DHCP and DNS server one box at a time, IPAM discovers them, inventories every address, and lets you administer DHCP scopes and DNS zones from one pane of glass with a full audit trail.

What it manages. Centralized IP tracking across all subnets, utilization monitoring (which scopes are filling up), DHCP scope and DNS zone administration, and an audit of who changed what and when. It is the tool you will wish you had during every IP-conflict outage.

Components. An IPAM SERVER (the role) backed by a DATABASE (Windows Internal Database for small shops, SQL Server at scale), the MANAGED SERVERS it controls (DHCP, DNS, domain controllers), and the IPAM client built into Server Manager.

Deployment order. Install the feature, provision the database, then run server DISCOVERY to find DHCP/DNS/DC servers in the domain. Granting IPAM rights over those managed servers is done by GPO or manually. Only then does utilization data start flowing.

NPS is Microsoft's RADIUS server: one central authority that authenticates, authorizes, and accounts for network access requests (AAA). Rather than every VPN box, wireless controller, and switch checking credentials on its own, they all defer to NPS, which checks against Active Directory and applies one consistent set of policies.

Use cases. VPN authentication, Wi-Fi via 802.1X, wired 802.1X port access, and acting as a RADIUS PROXY that forwards requests to another RADIUS server (useful across forests or to a partner).

Components. RADIUS clients are the network access devices (the VPN server, the wireless controller), NOT the end users. Connection request policies decide whether NPS handles a request locally or proxies it. Network policies grant or deny based on conditions (group membership, time, connection type). Accounting logs every request.

The flow. A user connects to a network access device; that device (a RADIUS client) forwards the request to NPS; NPS validates against AD, evaluates its network policies, and returns accept or reject with any conditions (VLAN assignment, session limits).

A remote-access VPN gives an off-site user an encrypted tunnel onto the corporate network. Windows RRAS supports several tunnelling protocols, and the choice is mostly about how the tunnel survives firewalls and network changes.

The protocols. IKEv2 is the recommended default: strong, fast, and its MOBIKE support reconnects seamlessly when a device changes networks. SSTP tunnels over TCP 443 (HTTPS), so it traverses almost any firewall. L2TP/IPsec is the older interoperable option. PPTP is obsolete with broken cryptography, avoid it.

Picking one. IKEv2 for mobile clients that roam between Wi-Fi and cellular. SSTP when restrictive firewalls block everything but 443. L2TP/IPsec only for legacy interoperability. For greenfield deployments, Microsoft now steers toward Always On VPN built on IKEv2.

Building it. Install the Remote Access (RRAS) role, enable the VPN role, and hand it an address pool to assign to connecting clients.

DirectAccess connects a domain-joined laptop to the corporate network AUTOMATICALLY whenever it has internet, with no user action and no VPN client to launch. To the user and to management tools, the machine is simply "on the network" wherever it is.

How it works. It is built on IPv6. Where the path is IPv4-only, transition technologies tunnel the traffic, most commonly IP-HTTPS (IPv6 inside HTTPS on 443) so it works through almost any firewall; 6to4 and Teredo are older options. The tunnel is bi-directional, so IT can push updates and policy to the client, and clients authenticate with MACHINE CERTIFICATES.

Requirements. Windows Enterprise edition, domain-joined clients, Active Directory with GPO, a PKI (AD CS) for the machine certificates, and a DirectAccess server. The PKI dependency is what makes it heavier to stand up than a plain VPN.

Modern note. DirectAccess is legacy; Microsoft now steers new deployments to Always On VPN, which delivers the same seamless always-connected experience on a simpler, IKEv2-based footing.

BranchCache cuts the bandwidth a branch office spends pulling the same content over a slow, expensive WAN link. The first client to fetch a file or web object caches it locally; every later client at that branch gets it from the local copy instead of crossing the WAN again.

Two modes. Distributed Cache: the cache is spread peer-to-peer across the branch client machines, no server needed, ideal for small offices. Hosted Cache: a dedicated branch server holds the cache, better for larger branches and always-available content.

What it caches. Content served over SMB (file shares), HTTP/HTTPS (web, WSUS, intranet), and BITS. The content server at HQ must have BranchCache enabled and generate content hashes.

The flow and its safety. First branch client pulls over the WAN and caches the content; subsequent clients retrieve it locally. Every local hit is HASH-VALIDATED against the origin, so a peer can never serve tampered or stale content, only an exact match of what HQ published.

A VLAN splits one physical switch into several logically separate networks. Devices in different VLANs cannot talk to each other directly even though they share the same hardware; traffic between them must pass through a router or firewall, where you can control and inspect it.

How it is carried. The 802.1Q standard tags each frame with a VLAN ID. An ACCESS port belongs to one VLAN and carries untagged traffic to an end device; a TRUNK port carries many tagged VLANs between switches (and to a Hyper-V host). The tag is what keeps the segments separate on a shared wire.

Why segment. Security isolation (keep the card-payment subnet away from guest Wi-Fi), broadcast containment (each VLAN is its own broadcast domain, so broadcast storms stay local), QoS boundaries, and multi-tenancy on shared infrastructure.

On Windows. Tag a physical adapter for the host, or set a Hyper-V virtual NIC to access mode on a specific VLAN so the VM sees only that segment.

SDN moves network configuration out of individual hardware boxes and into a central software control plane. You describe the network you want as policy, and the controller programs the underlying switches and hosts to match. It is the foundation of the Windows Server Datacenter networking stack.

Components. The Network Controller is the central brain that holds policy and pushes it down. The Software Load Balancer (SLB) distributes traffic across workloads. The RAS Gateway connects virtual networks to physical or remote sites. The Datacenter Firewall applies distributed, per-workload rules.

Benefits. Central management of the whole fabric, automated provisioning of new tenant networks in minutes, micro-segmentation (firewall policy that follows each workload), and full network virtualization decoupled from the physical topology.

The model. The network becomes API-driven: a single call to the Network Controller provisions a virtual network, instead of touching switches by hand.

Hyper-V Network Virtualization gives each tenant a complete virtual network that runs on top of the shared physical fabric, fully decoupled from it. Two tenants can even use the same IP range without conflict, because their addresses live in separate virtual networks.

The two address spaces. The Customer Address (CA) is the IP the VM believes it has, the one inside the tenant's virtual network. The Provider Address (PA) is the real IP on the physical fabric. HNV maintains the mapping between them so packets reach the right host.

Encapsulation. Tenant packets are wrapped (encapsulated) for transit across the physical network using VXLAN or NVGRE, then unwrapped at the destination host. The physical fabric only ever sees PA traffic; the CA networks ride inside.

Benefits. Multi-tenancy without VLAN sprawl (no 4096-VLAN ceiling), overlapping tenant IP spaces, and workload mobility, a VM can move across subnets or hosts and keep its CA address.

The host-based firewall built into every Windows machine filters traffic per machine, a critical layer even behind a perimeter firewall because it contains lateral movement once an attacker is already inside the network.

Three rule types. Inbound rules govern traffic arriving at the host (default: deny unless allowed). Outbound rules govern traffic leaving (default: allow). Connection Security rules establish IPsec-protected, authenticated connections between hosts.

Three profiles. The firewall applies a different rule set depending on the network the machine is attached to: Domain (joined network), Private (trusted home/office), and Public (untrusted, the most restrictive). The same machine tightens up automatically on coffee-shop Wi-Fi.

Matching. Rules match on program, port, protocol, and scope (address range), and resolve allow or block. Manage at scale by pushing firewall rules through Group Policy rather than per-machine.

IPsec secures traffic at the IP layer, transparently to applications. It can authenticate that a peer is who it claims to be, guarantee that packets were not altered in transit, and encrypt the payload so it cannot be read. In Windows it is configured through Connection Security rules.

Two modes. Transport mode protects just the packet PAYLOAD and is used host-to-host inside a network (for example, encrypting traffic to a domain controller). Tunnel mode wraps the ENTIRE packet inside a new one and is used site-to-site, the basis of IPsec VPNs.

Authentication options. Kerberos (seamless for domain members, the usual choice), certificates (for non-domain or cross-org peers), or a pre-shared key (simple, but the weakest, use only for testing).

Negotiation. Peers use IKE to authenticate and agree on keys before any protected traffic flows. A Windows IPsec rule can require, request, or only-when-available security per traffic match.

QoS makes sure the traffic that matters gets the bandwidth it needs when the link is congested. Without it, a backup job or a large download can starve latency-sensitive traffic like voice and video; with it, you reserve priority for the important flows and cap the greedy ones.

Two levers. DSCP marking tags packets with a priority value (for example, DSCP 46 / Expedited Forwarding for VoIP) that QoS-aware switches and routers honor end to end. Throttle rate caps how much bandwidth a flow may consume, so bulk transfers cannot saturate the link.

Targeting traffic. A QoS policy can match by APPLICATION (the executable path, e.g. backup.exe) or by PORT/protocol (e.g. the SIP ports for voice). You apply policies through Group Policy for domain-wide consistency or locally on a single host.

The pattern. Mark and prioritize what is latency-sensitive; throttle what is bulk and can wait. The example below does both.

NAT rewrites the IP addresses in packet headers as they cross a boundary, letting a network of private addresses share public address space and letting you publish an internal service without exposing its real address.

Directions and strategies. SNAT (source NAT, outbound) rewrites the source so many internal hosts share one external IP. DNAT (destination NAT / port forwarding, inbound) maps an external port to an internal service. Static 1:1 dedicates one external IP to one internal host. Dynamic pool draws external addresses from a shared range as needed.

Where it matters. The classic case is private clients reaching the internet through one public address. On Windows it also isolates lab and container subnets: a Hyper-V internal switch plus NAT gives VMs and containers outbound access without putting them on the corporate LAN.

On Windows. Create a NAT for the internal prefix, then add static mappings for any inbound port forwards.

When the network misbehaves, Windows ships a layered toolkit so you can move from "is it reachable?" to a full packet capture without installing anything. The skill is knowing which tool answers which question and working the layers in order.

The core cmdlets. Test-NetConnection tests reachability to a host and port (the modern ping-plus-port-check). Get-NetTCPConnection lists active connections and their states. Get-NetRoute shows the routing table to confirm traffic leaves the right interface. netsh trace captures packets to an ETL file for deep analysis.

Performance counters. For throughput and saturation questions, watch counters such as Network Interface Bytes/sec, TCPv4 Connections Established, Network Adapter Packets/sec, and RDMA Activity. They reveal a link that is up but overloaded.

The method. Test connectivity to the target first; if that fails, inspect routing and active connections; if the cause is still unclear, capture packets and analyze. Escalate down the stack only as far as the symptom requires.

Two labs cover the same advanced-networking build from complementary angles. Do them in sequence: the GUI lab builds the mental model and shows what each wizard is doing; the PowerShell lab makes it repeatable for the next environment you stand up.

GUI Lab (Server Manager + consoles). Create a NIC team and configure DHCP failover; author DNS policies; build firewall rules and a QoS policy; verify each through its management console.

PowerShell Lab. The same operations as a repeatable script: teams and failover, DNS zone scopes and policies, firewall and IPsec connection-security rules, and QoS policies, end to end.