PowerShell

Explains what PowerShell execution policies are, the available levels (Restricted, RemoteSigned, AllSigned, Bypass and others) and the scopes they apply to. It also stresses the policy is a safety net rather than a security boundary, and shows how to check and change it per user, machine or session. Loosening it (for example Unrestricted or Bypass) reduces protection, so prefer the narrowest scope.

A user got Access denied running Invoke-Command against localhost even though WinRM was started. The answer explains Invoke-Command needs PowerShell remoting enabled even for the local machine, and suggests setting WinRM to Automatic, starting it and enabling remoting. The answer writes the cmdlet as EnablePSRemoting; the real name is Enable-PSRemoting. Enabling remoting opens a WinRM listener, so only do it where you need it.

Question-and-answer guide to running PowerShell commands on other computers: how remoting works over WS-Management, Invoke-Command versus a persistent PSSession, throttling, serialized output and profiles not loading in remote sessions. It also covers workgroup and cross-domain caveats such as TrustedHosts, and remoting over SSH.

An accepted answer to how to run a locally-working command on other computers. It says to enable PowerShell remoting on the target first (on by default on servers, not on clients, and a security consideration), allow it through the firewall if not on a domain, then create a session with New-PSSession and run the script block with Invoke-Command.

Reference for the cmdlet that configures a Windows machine to receive remote PowerShell commands: it starts WinRM, creates listeners and firewall exceptions, and enables session configurations. It notes that public-network profiles are blocked on client Windows unless -SkipNetworkProfileCheck is used, and that PowerShell 7 and Windows PowerShell endpoints are configured separately. Remoting opens a listener, so only enable it where needed.