Networking Tools and Remote Access

netstat -ano combines three flags: -a (all connections and listening ports), -n (show numeric IP/port rather than resolving names — faster), -o (show the owning process ID). Output columns: Proto (TCP or UDP), Local Address (IP:port on this machine — 0.0.0.0 or :: means listening on all interfaces), Foreign Address (remote IP:port — 0.0.0.0:0 for listeners), State (LISTEN, ESTABLISHED, TIME_WAIT, CLOSE_WAIT, FIN_WAIT), PID. For IIS work: findstr LISTEN to see all open ports; findstr :80 to check who specifically owns port 80.

Ping failure (ICMP unreachable/timeout) means you cannot reach the host at Layer 3 (IP routing), the host is offline, or ICMP is blocked by a firewall. Port failure (Test-NetConnection or telnet refusing) means the host is reachable at IP level, but the specific TCP port is not open — either the application is not listening, the application crashed, or a firewall is blocking that specific port. IIS servers typically block ICMP in production (security hardening) while keeping ports 80/443 open. Always test the actual port before concluding a server is down based only on ping.

DNS (Domain Name System) is the distributed directory service that translates hostnames (www.example.com) to IP addresses (93.184.216.34). IIS is critical because: IIS uses Host Headers to route incoming requests to the correct site when multiple sites share one IP. If DNS resolves a hostname to the wrong IP, requests never reach the correct server. SSL certificates are issued for specific domain names — if DNS doesn't resolve to the cert's CN/SAN, browsers show certificate errors. During failover or IP changes, DNS TTL determines how long until clients see the new address — short TTLs (300 seconds) allow faster failover for IIS migrations.

WinRM (Windows Remote Management) is Microsoft's implementation of the WS-Management protocol, enabling remote management commands and PowerShell remoting. It listens on port 5985 (HTTP transport, unencrypted but with Windows authentication) and port 5986 (HTTPS transport, encrypted). WinRM must be explicitly enabled on the target server: winrm quickconfig enables the listener and opens the firewall rule. Once enabled, administrators can run Enter-PSSession -ComputerName hostname for interactive remote shells or Invoke-Command for scripted remote execution — critical for managing IIS in automation pipelines and across server farms.

TIME_WAIT is the TCP state after a connection has been closed from this machine's side. TCP requires a 4-minute wait (2 * Maximum Segment Lifetime) before the port/address tuple can be reused, ensuring all packets from the closed connection have drained from the network. For IIS: some TIME_WAIT connections are normal. Hundreds or thousands of TIME_WAIT connections per second indicate a high-throughput site or — if the count grows unbounded — a connection pool that is not reusing connections properly. In HTTP/1.0 without keep-alive, every request creates and tears down a connection, generating TIME_WAIT. Fix: ensure HTTP/1.1 keep-alive is enabled in IIS and ensure clients (reverse proxies, load balancers) use persistent connections.

Use Test-NetConnection -ComputerName <hostname> -Port <port> from any Windows machine with network access. This is the most direct method — it attempts a full TCP 3-way handshake and reports TcpTestSucceeded: True or False. Alternatively: curl -v http://hostname:port for HTTP layer testing. From outside: online port checkers test from the internet perspective. For batch testing multiple ports: 80,443,8080 | ForEach-Object { Test-NetConnection -ComputerName web01 -Port $_ }. Combine with Select-Object ComputerName,RemotePort,TcpTestSucceeded for a readable matrix.

HTTP.sys uses URL namespace reservations (URL ACLs) to determine which HTTP.sys-registered applications receive which URLs. Each entry shows: a URL prefix (e.g., http://+:80/) and which user account has Listen rights. IIS registers its sites here automatically when configured in IIS Manager. This matters when: (1) IIS refuses to start because another app already registered the URL (e.g., BranchCache, WCF, SQL Reporting Services all compete for http://+:80/). (2) A non-IIS .NET application (self-hosted WCF) fails with "address already in use" — actually it needs its own URL ACL reservation. (3) You need to remove a stale registration after uninstalling an application that still has a URL reserved.

SSL certificate bindings in IIS associate a specific certificate (by thumbprint) with an IP+port combination in HTTP.sys. When a HTTPS request arrives, HTTP.sys uses this binding to present the correct certificate for the TLS handshake before any IIS application code runs. netsh http show sslcert shows all registered SSL certificate bindings: IP:port (or hostname:port for SNI), certificate hash (thumbprint), application GUID (identifies whether it's IIS or another app), and certificate store. Useful when: the browser shows "expired certificate" even after installing a new one (the old thumbprint is still in the SSL cert binding — update the IIS site binding to the new cert). Or when a site returns a different site's certificate (SNI misconfiguration).

Remote Desktop Protocol (RDP) allows graphical remote sessions to Windows servers over TCP port 3389 (default). RDP sessions are encrypted using TLS. Security risks: (1) Brute force attacks against local/domain credentials on exposed port 3389 — mitigate with account lockout and NLA (Network Level Authentication, enabled by default on Server 2016+). (2) BlueKeep and other RDP CVEs — keep OS patched. (3) Lateral movement — if an attacker gains RDP access, they can pivot to other systems. Mitigations for IIS servers: restrict RDP access to management VLAN only, require MFA (via Azure AD or NPS with RADIUS), use Just-in-Time (JIT) access via Azure Security Center, or replace with Windows Admin Center over HTTPS.

Secure WinRM setup: (1) Enable WinRM with HTTPS only: winrm quickconfig -transport:https — requires a valid SSL certificate on the target. (2) Configure HTTPS listener with a certificate: winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="server01.corp.com"; CertificateThumbprint="AABBCC..."}. (3) Restrict to specific admin accounts via WinRM access policy. (4) At enterprise scale, deploy via GPO: Computer Configuration → Windows Settings → Security Settings → Windows Firewall with Advanced Security (allow port 5986 from management VLAN). (5) Use JEA (Just Enough Administration) to restrict what remote users can do: define role capability files limiting commands to IIS-specific operations only — admins can restart app pools but cannot access the file system or modify security settings.

Layer by layer: 1. From client: Test-NetConnection -ComputerName webserver -Port 443 → TcpTestSucceeded: False. 2. On server (RDP in): netstat -ano | findstr :443 → no listener on 443. IIS is not listening. 3. sc query http → Running. HTTP.sys is up. 4. Open IIS Manager → sites → check the HTTPS binding exists. If missing → add it. 5. If binding exists: netsh http show sslcert — does 0.0.0.0:443 or the site's IP:443 appear? If missing, the SSL cert binding was deleted. Re-add in IIS Manager → Bindings → Edit → select correct certificate. 6. If the certificate thumbprint in the registry points to a deleted/expired cert, the binding will fail silently. Install a valid cert, then update the binding. Test with curl -v -k https://localhost after each change.

This is a DNS and/or Host Header configuration problem. Steps: 1. nslookup mysite.example.com from the client — does it resolve? If no resolution: DNS record missing. Create an A record pointing the hostname to the server IP. 2. If it resolves but to wrong IP — stale DNS record. Update the A record and flush DNS: ipconfig /flushdns. 3. If DNS resolves correctly but site still won't load: check IIS Site Bindings — if the site binding has a specific Host Name set (e.g., mysite.example.com), requests arriving with the wrong Host header are rejected. If Host Name is blank in the binding, IIS accepts any hostname for that IP:port. 4. If multiple sites on the same IP: the site must have the correct hostname in its binding to distinguish it from the default site. This is a classic misconfiguration in multi-tenant IIS environments.

CLOSE_WAIT means the remote end (clients) has closed the TCP connection (sent FIN to the server) but the local application (w3wp.exe) has not yet closed its end. It is waiting for the application to call close() on the socket. Large numbers of CLOSE_WAIT accumulating (not cycling back to CLOSED) indicate a socket leak in the application — the worker process is not properly closing connections after the client disconnects. Root cause: application holding database connections or upstream API connections open even after the client request ends. Fix: ensure all HttpClient, SqlConnection, and stream objects are properly disposed (using statements in .NET). Check IIS keep-alive settings — if clients are disconnecting because of aggressive timeout but the server-side code loops waiting for more data, it will build CLOSE_WAIT. Schedule a w3wp recycle as immediate mitigation to release the leaked sockets.

Yes, via IIS Host Head Bindings. HTTP.sys owns port 80 and routes incoming requests based on the HTTP Host header. Configure each site in IIS with the same port but different Host Name values: Site A → port 80, hostname: app1.company.com. Site B → port 80, hostname: app2.company.com. When a request for app1.company.com arrives, HTTP.sys inspects the Host header and routes only to Site A's app pool. Both sites coexist on port 80. Requirements: DNS must resolve each hostname correctly, each site's binding must have the hostname field populated (otherwise IIS creates an ambiguous binding and only one site will catch requests). For HTTPS: SNI (Server Name Indication) is the equivalent mechanism, allowing different SSL certificates per hostname on port 443.

With WinRM enabled on the target, use: Invoke-Command -ComputerName webserver01 -ScriptBlock { iisreset }. This runs iisreset on the remote server and streams the output back to your console. For persistent sessions: $session = New-PSSession -ComputerName webserver01; Invoke-Command -Session $session -ScriptBlock { Import-Module WebAdministration; Restart-WebAppPool "MyPool" }. Security best practice: if the executing account is already a member of the local Administrators group on the remote server via domain group membership, WinRM uses Kerberos authentication automatically — no credentials need to be embedded in scripts. Use JEA (Just Enough Administration) to create a restricted endpoint that only exposes IIS management cmdlets if you want to grant restartability without full admin rights.