Troubleshooting

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. ...

Office deployment and Active Directory maintenance often land on the same admin desk. This post collects the PowerShell workflows I use for silent Office installs, Office activation firewall rules, Get-ADUser reporting, and domain rejoin cleanup when a Windows device has stale identity state. Quick answer Use PowerShell to make Office and Active Directory work repeatable: deploy Office with the Office Deployment Tool and a checked configuration.xml, open only the firewall rules needed for activation, export AD user data with Get-ADUser, and fix stale device identity by checking domain join, Azure AD join, and dsregcmd output before rejoining the computer. ...

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. ...