How to control your PC from your mobile phone using PowerShell Remoting

You may already automate many tasks with PowerShell locally, but where do you really PowerShell Remoting makes the difference It is when you run commands on remote machines, whether a few or hundreds, interactively or in parallel. This technology, available since Windows PowerShell 2.0 and enhanced since 3.0, is based on WS-Management (WinRM) and converts PowerShell in a robust, scalable and secure remote management channel.

First of all, it is important to understand two key ideas: cmdlets with -ComputerName parameter (e.g., Get-Process or Get-Service) are not the long-term path recommended by Microsoft, and PowerShell Remoting does not work as a “hack.” In fact, enforces mutual authentication, audit logs and respects your usual permissions, without storing credentials or magically running anything with super privileges.

What is PowerShell Remoting and why use it?

With PowerShell Remoting can execute almost any command remotely that you could launch in a local session, from querying services to deploying configurations, and do so on hundreds of computers at once. Unlike cmdlets that accept -ComputerName (many use DCOM/RPC), Remoting travels via WS-Man (HTTP/HTTPS), which is more firewall-friendly, allows parallelism and offloads work to the remote host, not the client.

This translates into three practical advantages: better performance in massive executions, less friction in networks with restrictive rules and a security model consistent with Kerberos/HTTPS. Furthermore, by not depending on each cmdlet to implement its own remote, Remoting It works for any script or role that is available at the destination.

By default, recent Windows Servers come with Remoting enabled; in Windows 10/11 you activate it with a single cmdlet. And yes, you can use alternate credentials, persistent sessions, custom endpoints, and more.

Note: Remoting is not synonymous with opening everything. By default, only administrators They can connect, and actions are executed under their identity. If you need fine-grained delegation, custom endpoints allow you to expose only the essential commands.

How it works inside: WinRM, WS-Man and ports

PowerShell Remoting works in a client-server model. The client sends WS-Management requests via HTTP (5985/TCP) or HTTPS (5986/TCP). On the target, the Windows Remote Management (WinRM) service listens, resolves the endpoint (session configuration), and hosts the PowerShell session in the background (wsmprovhost.exe process), returning serialized results to the client in XML via SOAP.

The first time you enable Remoting, listeners are configured, the appropriate firewall exception is opened, and session configurations are created. From PowerShell 6+, multiple editions coexist, and Enable-PSRemoting Registers endpoints with names that reflect the version (for example, PowerShell.7 and PowerShell.7.xy).

If you only allow HTTPS in your environment, you can create a safe listener with a certificate issued by a trusted CA (recommended). Alternatively, another alternative is to use TrustedHosts in a limited, risk-aware manner, for workgroup scenarios or non-domain computers.

Note that Powershell Remoting can coexist with cmdlets with -ComputerName, but Microsoft pushes WS-Man as the standard and future-proof way for remote administration.

Enabling PowerShell Remoting and Useful Parameters

On Windows, just open PowerShell as administrator and run Enable-PSRemoting. The system starts WinRM, configures autostart, enables the listener, and creates the appropriate firewall rules. On clients with a public network profile, you can deliberately allow this with -SkipNetworkProfileCheck (and then reinforce with specific rules):

Enable-PSRemoting
Enable-PSRemoting -Force
Enable-PSRemoting -SkipNetworkProfileCheck -Force

 

The syntax also allows, -Confirm y -WhatIf for change control. Remember: It is only available on Windows, and you must run the elevated console. The rules created differ between Server and Client editions, especially on public networks, where by default they are limited to the local subnet unless you expand the scope (for example, with Set-NetFirewallRule).

To list already recorded session configurations and confirm that everything is ready, use Get-PSSessionConfigurationIf the PowerShell.x and Workflow endpoints appear, the Remoting framework is operational.

Usage modes: 1 to 1, 1 to many, and persistent sessions

When you need an interactive console on a single computer, turn to Enter-PSSessionThe prompt will appear, and everything you execute will go to the remote host. You can reuse credentials with Get-Credential to avoid constantly re-entering them:

$cred = Get-Credential
Enter-PSSession -ComputerName dc01 -Credential $cred
Exit-PSSession

If what you are looking for is to send commands to several computers at once, the tool is Invoke-Command with a scriptblock. By default, it launches up to 32 concurrent connections (adjustable with -ThrottleLimit). The results are returned as deserialized objects (without “live” methods):

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service -Name W32Time } -Credential $cred

Need to invoke a method like .Stop() or .Start()? Do it. inside the scriptblock in the remote context, not the local deserialized object, and that's it. If there's an equivalent cmdlet (Stop-Service/Start-Service), it's usually preferable to use it for clarity.

To avoid the cost of starting and ending sessions on each call, create a Persistent PSSession and reuse it across multiple invocations. Use New-PSSession to create the connection, and use Invoke-Command-Session to reuse the tunnel. Don't forget to close it with Remove-PSSession when you're done.

Serialization, limits and good practices

An important detail: when traveling, objects "+flatten" and arrive as deserialized snapshots, with properties but no methods. This is deliberate and saves bandwidth, but it means you can't use members that execute logic (like .Kill()) on the local copy. The solution is obvious: invoke those methods. remotely and if you only need certain fields, filter with Select-Object to send less data.

In scripts, avoid Enter-PSSession (intended for interactive use) and use Invoke-Command with script blocks. If you anticipate multiple calls or need to preserve state (variables, imported modules), use persistent sessions and, if applicable, disconnect/reconnect them with Disconnect-PSSession/Connect-PSSession in PowerShell 3.0+.

Authentication, HTTPS, and Off-Domain Scenarios

In a domain, native authentication is Kerberos And everything flows. When the device can't verify the server name, or you connect to a CNAME IP or alias, you need one of these two options: 1) Listener HTTPS with certificate issued by a CA you trust, or 2) add the destination (name or IP) to TrustedHosts and use credentialsThe second option disables mutual authentication for that host, so it reduces the scope to the minimum necessary.

Setting up an HTTPS listener requires a certificate (ideally from your PKI or a public CA), installed in the team store and bound to WinRM. Port 5986/TCP is then opened in the firewall and, from the client, used. -UseSSL in remote cmdlets. For client certificate authentication, you can map a cert to a local account and connect with -CertificateThumbprint (Enter-PSSession does not accept this directly; create the session first with New-PSSession.)

The second hop and delegation of credentials

The famous “double hop” appears when, after connecting to a server, you need that server to access a third resource on your behalf (e.g., an SMB share). There are two approaches to allowing this: CredSSP and resource-based constrained Kerberos delegation.

With CredSSP You enable the client and intermediary to explicitly delegate credentials, and you set a policy (GPO) to allow delegation to specific computers. It's quick to configure, but less secure because the credentials travel in clear text within the encrypted tunnel. Always limit sources and destinations.

The preferred alternative in domain is the constrained Kerberos delegation (resource-based constrained delegation) in modern AD. This allows the endpoint to rely on receiving delegation from the middlepoint for specific services, avoiding exposing your identity on the initial connection. Requires recent domain controllers and an updated RSAT.

Custom Endpoints (Session Configurations)

One of the gems of Remoting is being able to register connection points with tailored capabilities and limits. First you generate a file with New-PSSessionConfigurationFile (modules to preload, visible functions, aliases, ExecutionPolicy, LanguageMode, etc.), and then you register it with Register-PSSessionConfiguration, where you can set RunAsCredential and permissions (SDDL or GUI interface with -ShowSecurityDescriptorUI).

For safe delegation, expose only what is necessary with -VisibleCmdlets/-VisibleFunctions and disable free scripting if appropriate with LanguageMode RestrictedLanguage or NoLanguage. If you leave FullLanguage, someone could use a script block to invoke unexposed commands, which, combined with RunAs, it would be a hole. Design these endpoints with a fine-tooth comb and document their scope.

Domains, GPOs, and Groupware

In AD you can deploy Powershell Remoting at scale with GPO: allow automatic configuration of WinRM listeners, set the service to Automatic, and create the firewall exception. Remember that GPOs change settings, but they don't always turn on the service instantly; sometimes you need to restart or force a gpupdate.

In workgroups (non-domain), configure Remoting with Enable-PSRemoting, set TrustedHosts on the client (winrm set winrm/config/client @{TrustedHosts=»host1,host2″}) and use local credentials. For HTTPS, you can mount self-signed certificates, although it is recommended to use a trusted CA and validate the name that you will use in -ComputerName in the certificate (CN/SAN match).

Key cmdlets and syntax

A handful of commandos cover the 90% of daily scenarios. To activate/deactivate:

Enable-PSRemoting    
Disable-PSRemoting

Interactive session 1 to 1 and exit:

Enter-PSSession -ComputerName SEC504STUDENT 
Exit-PSSession

1 to many, with parallelism and credentials:

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service W32Time } -Credential $cred

Persistent sessions and reuse:

$s = New-PSSession -ComputerName localhost -ConfigurationName PowerShell.7
Invoke-Command -Session $s -ScriptBlock { $PSVersionTable }
Remove-PSSession $s

Testing and WinRM Useful:

Test-WSMan -ComputerName host
winrm get winrm/config
winrm enumerate winrm/config/listener
winrm quickconfig -transport:https

Practical notes on firewall, network and ports

Open 5985/TCP for HTTP and 5986/TCP for HTTPS on the target computer and on any intermediate firewallOn Windows clients, Enable-PSRemoting creates rules for domain and private profiles; for public profiles, it's limited to the local subnet unless you modify the scope with Set-NetFirewallRule -RemoteAddress Any (a value you can assess based on your risk).

If you use SOAR/SIEM integrations that run remote commands (e.g. from XSOAR), make sure the server has DNS resolution to the hosts, connectivity to 5985/5986, and credentials with sufficient local permissions. In some cases, NTLM/Basic authentication may require adjustment (e.g., using a local user in Basic with SSL).

Enable-PSRemoting Parameters (Operational Summary)

-Confirm asks for confirmation before executing; -Force ignores the warnings and make the necessary changes; -SkipNetworkProfileCheck enables Remoting on public client networks (limited by default to the local subnet); -WhatIf shows you what would happen without applying changes. Additionally, like any standard cmdlet, it supports common parameters (-Verbose, -ErrorAction, etc.).

Remember that “Enable” does not create HTTPS listeners or certificates for you; if you need end-to-end encryption from the start and authentication based on certificates, configure the HTTPS listener and validate CN/SAN against the name you will use in -ComputerName.

Useful WinRM and PowerShell Remoting Commands

essential bedside items For the day to day:

winrm get winrm/config
winrm enumerate winrm/config/listener
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress Any
Test-WSMan -ComputerName host -Authentication Default -Credential (Get-Credential)
New-PSSession -ComputerName host 
Enter-PSSession -ComputerName host 
Enable-PSRemoting -SkipNetworkProfileCheck -Force

When managing Windows at scale, Remoting allows you to move from "computer-to-computer" to a declarative and secure approach. By combining persistent sessions, strong authentication (Kerberos/HTTPS), restricted endpoints, and clear traces for diagnostics, you gain speed and control without sacrificing security or auditing. If you also standardize GPO activation and master special cases (TrustedHosts, double hop, certificates), you'll have a solid remote platform for daily operations and incident response.