PowerShell's Remote Control in a Nutshell

 Jan 13, 2014

Remote control of servers and workstations can be implemented in a number of ways. For example, administrators and help desk support personnel have been using Remote Desktop Protocol (RDP) connections for years. This was fine for most servers, but it became more problematic when trying to support workstations with already logged in users. PowerShell however bumps the whole remote control thing up a few notches and gives us a number of new remote control options. The purpose of this post is to give you a brief rundown on these options, along with their advantages and disadvantages.

Traditional or Classic Remoting

A number of PowerShell cmdlets support accessing information on remote computers (e.g. Get-WMIObject or Get-Service etc.). These commands have a –computername parameter and are referred to as Traditional or Classic remoting. Some purists do not consider this as a true form of PowerShell remoting as it relies upon the developers of each cmdlet to implement the remote access methods, meaning their remoting capability is independent of PowerShell itself. In general, these cmdlets are easy to implement, intuitive and give us some extremely useful functionality. However, they do have one major drawback – most of them depend upon the DCOM and RPC protocols, and these protocols require opening multiple ports in the firewall and possibly starting various services on the target that the different cmdlets utilise, although the majority of these commands do tend to use well-known APIs. This approach means that not all PowerShell cmdlets support this type of remoting. It also means their remoting methodology is not always consistent, and they are generally firewall unfriendly. They can also use communications protocols that are related to their own specific technologies (e.g. the AD DS and Exchange cmdlets etc.), which is both an advantage and disadvantage of this approach. Some of these cmdlets also allow you to specify different credentials for the remote connection using the –credentials parameter. If you did not specify the –credentials parameter, or if the cmdlet does not support it, then PowerShell defaulted to the logged in user’s credentials, although you could “cheat” a bit here by opening the PowerShell window using the “Run as different user” or the “Run as Administrator” options.

PowerShell Remoting

PowerShell v2.0 was a real game changer here – it enabled you to make a remote connection to, open a remote shell or session on a target computer, and run cmdlets or even scripts directly on that computer. It also allowed you to manage multiple computers with a single command, and of course this meant that all cmdlets installed on the remote computer now inherently have remote capabilities through PowerShell Remoting, and don’t rely on having their own –computername parameter or other remote connectivity capability. PowerShell Remoting uses Windows Remote Management (WinRM), and having this service running on the target computer(s) is a requirement for PowerShell Remoting, along with .NET Framework 2.0 or higher, and PowerShell 2.0 or higher. WinRM is now automatically enabled on Windows Server 2012 and Windows Server 2012 R2, but on all other systems, such as Windows 7, 8, 8.1, Server 2008, etc. it needs to be explicitly enabled. The cmdlet Enable-PSRemoting can be used to enable the WinRM service (and create the appropriate firewall exceptions and listeners), or it can be enabled via Group Policy. Please note that other than through Group Policy, WinRM cannot be enabled remotely. PowerShell v3.0 (integrated into Windows 8 and Windows Server 2012), is now part of Windows Management Framework 3.0 (WMF3), which now also includes the WinRM service to support remoting. PowerShell v3.0 brought in the ability to disconnect and reconnect to sessions (and sessions are now more resilient to temporary network failures), the ability to schedule jobs, as well as allowing individual tasks to be delegated to users who do not have permissions for that type of task, without granting them perpetual additional permissions. It also includes code autocompletion (IntelliSense) and Snippets. PowerShell v4.0 (integrated into Windows 8.1 and Windows Server 2012 R2) brought in the ability to perform Desired State Configuration checks, changed the Default Execution Policy from Restricted to RemoteSigned, and gave use a number of enhanced debugging options, including support for debugging workflows, remote script execution and preserving debug sessions across PowerShell session reconnections. So there you have it – PowerShell Remoting gives Administrators and Support Personnel much greater flexibility and the ability to manage your remote computers more easily, with less overhead than a console session and the ability to quickly automate much of your administrative and support functions. And of course, if you want to be an effective server administrator these days (or an Exchange Administrator, or SQL Administrator or SharePoint Administrator etc.) you really do need to become familiar with PowerShell. To find out more about PowerShell or PowerShell Remoting, be sure to take a look at the large range of Server Administration and PowerShell courses offered by New Horizons.

How do your Excel skills stack up?   

Test Now  

About the Author:

Gordon Cowser  

With over 22 years real world and training experience, Gordon is our most senior IT Infrastructure trainer. His expertise includes but is not limited to; Microsoft Server and Client OS, Messaging, Collaboration, Active Directory and Network Infrastructure. Gordon also specialises in SharePoint technologies training in both technical and end user aspects. With his extensive skill-set he brings a thorough mentoring capability to the classroom where he can advise on technical issues and challenges often beyond the scope of the course curriculum. A very approachable and experienced training professional, he has the ability to establish credibility fast with students at all levels.

Read full bio
top
Back to top