Networking

These are Windows troubleshooting notes I keep coming back to: SMB errors that block file shares, WSL refusing to start, Windows 11 complaining about TPM in VMware, and disk space disappearing after background downloads. The common thread is simple: start with the error, isolate the layer that is failing, and fix that layer before changing everything around it. Quick answer For Windows troubleshooting, start by proving which layer is broken before changing settings. For SMB share errors, test port 445, credentials, and SMB signing. For WSL crashes, restart WSL, check the distribution state, and confirm virtualization is healthy. For VMware Windows 11 install problems, verify TPM and Secure Boot settings. For disk space issues, find the folder consuming space before deleting files. ...

Software inventory is one of those jobs that sounds simple until you need to do it across many Windows machines. For audits, license checks, cleanup work, or troubleshooting, I want a repeatable way to answer one question: what is installed, and where? This post uses PowerShell to build that report. The workflow is: get a target computer list from DNS, connect to each machine, read installed-app registry keys, and export the result to CSV. ...

When I need to move large files between Windows systems, I do not pick a tool by habit. LAN copies, WAN copies, and PowerShell remoting copies behave very differently. This post compares SCP (OpenSSH), Robocopy (SMB), and Copy-Item (WinRM) for the kinds of transfers I actually run. The short version: Robocopy is usually best on a LAN, SCP or rsync is usually safer across untrusted or unstable networks, and Copy-Item is convenient for small files inside an existing PowerShell remoting workflow. ...

When an application cannot connect, I usually test the port before changing firewall rules or blaming DNS. A quick TCP test tells me whether the client can reach the service at all. These are the Windows tools I use most often: Test-NetConnection, a small .NET TcpClient check, Telnet, and PortQry. Quick answer To test whether a TCP port is open from Windows, run Test-NetConnection -ComputerName servername -Port 443 and check TcpTestSucceeded. True means the client reached the service on that port. False means the port is closed, blocked by a firewall, the service is not listening, or the network path is unavailable. On older systems, use Telnet, PortQry, or a .NET TcpClient test. ...