PowerShell Remoting really can makes a routine work a lot easier, but it requires quite a bit of work to get all the remote computers ready to take the remoting calls, such as automatically start Windows Remote Management service, set up the HTTP listener for incoming WinRM requests, as well as open Firewall Port to allow the traffic to go through.
For individual computers
To begin, open a PowerShell as Administrator window on the computer and run the following cmdlet and it will take care of the rest:
For Large Network
Deploying the settings via Group Policy is definitely the way to go. If you are on Windows Server 2012 R2, open Group Policy Management and find the Grou Policy object you want to tweak and edit from there. Or create a new one if needed.
Once you are in there, there are three places that you need to go through:
Allow remote server management through WinRM
Go to Computer Configuration > Policies > Administrative Templates > Windows Remote Management (WinRM) > WinRM Service.
Double-click the setting Allow remote server management through WinRM:
Select Enable and type in * in for both IPv4 filter and IPv6 filter.
Click OK to close the window.
If you don’t see Windows Remote Management in your Group Policy Editor, there is probably the WinRM admin template missing in your Active Directory.
Enable WinRM service
Go to Computer Configuration > Policies > Preferences > Control Panel Settings, then right-click Services and choose New > Service.
Choose Automatic (Delayed Start) as startup type, pick WinRM as the service name, set Start service as the action.
Click OK to save the change.
Set up the Firewall Rule
Go to Computer Configuration > Policies > Security Settings > Windows Firewall with Advanced Security, then right-click Inbound Rules and start a New Rule…
Select Predefined: option and choose Windows Remote Management from the list (not the one with compatible). Click Next.
Select the one for Domain and Private, and select Allow the connection option at the next screen. And click Finish.
To reduce the exposure to this service we can remove the Private and only leave only Domain profile in place. Double-click the new rule we just created, go to Advanced tab and uncheck the Private option from the Profiles section.
Test it out
You can scan the port 5985 on the remote computer to see if it responses, like below:
|Test-NetConnection -ComputerName remote_computer -Port Port#|
Oh, simply open a PowerShell session on the remote computer and see if it succeeds.
|Enter-PSSession -ComputerName remote_computer|
One more thing to talk about is who is allowed to connect to servers or computers using Powershell Remoting. There are two possible answers to this query:
- For Windows 7 and Windows Server 2008 R2 only the members of the local Administrators group have access to remoting.
- For anything newer than Windows 7/2008 R2 there is the Administrators group and the Remote Management Users group.
In order for Powershell Remoting to be usable, 3 settings need to be configured:
- A listener that has the job to wait for incoming requests.
- A firewall rule that permits the remoting traffic.
- The WinRM service which implements the WSMan protocol which Powershell Remoting uses has to be running and it’s startup set to automatic delayed.
For some versions of operating systems some of these settings or all are already configured by default. If you have a complex infrastructure and want remoting on everything (clients and servers) all 3 settings will have to be configured. Let’s see what every OS has by default:
- Windows Server 2012 and later server OSes have everything already set.
- Windows Server 2008 R2 has the 3rd setting configured so if targeting this OS, just configure the first 2 settings.
- Windows client OSes from Windows 7 and up do not have any of the 3 settings configured so all 3 have to be set.
So if you only want remoting on servers and have just Windows Server 2012 and up, you are already done: remoting is enabled.