The Windows Remote Management (a.k.a. WinRM) interface is a network service that allow remote management access to computer via the network. It’s used frequently as a conduit to allow remote management of computer via PowerShell. As a result WinRM is enabled by default on Windows Server 2012 to enable the Server Manager tool but it is not enabled for Windows client OS’s by default.
As it is turned off by default on client OS’s the following describes how you can enable it using Group Policy.
Firstly create a Group Policy Object that targets the workstation that you want to enable the WinRM (e.g. “Enable WinRMâ€)
Then enable the “Allow remote server management through WinRM†policy setting found under Computer > Policies > Windows Components > Windows Remote Management (WinRM) > WinRM Service. From here you need to specify the IP Address ranges that the service will accept connections from, be cautious if you just add “*†in the field as this can potentially allow incoming connection form all network locations. If possible specify the exact IP ranges that you will be performing the remote management from to reduce the risk of connection coming in from any computer.
Note: This policy is also know as “Allow automatic configuration of listenersâ€
Next we need to enable the “Windows Remote Management (WS-Management)†Service via the Group Policy Preferences Services.
And finally we need to open up the firewall rules to allow the incoming TCP connection on the Domain Network profile.
Go to Computer Configurations > Policies > Security Settings > Windows Firewall and Advanced Security > Windows Firewall and Advanced Security then right click on “Inbound Rules†and click on the “New Rule…†option.
Check the “Predefined†option and select “Windows Remote Management†from the pop-down list and Click “Nextâ€
Then uncheck the top “Public†rule to again reduce the exposure of this services to the internet and then click “Nextâ€
Then click “Finishâ€
And you should now have a new listed as similar to below.
To again reduce the exposure of this service again you can double click on the new rule you just created and remove the “Private†from the network profiles that this applies.
You have now enable WinRM on your workstations that is required to allow you run PowerShell remote commands against.
As you might already realise enabling this should not be taken lightly as you are essentially opening up a way to completely remote control your computers. This is why should always limit the scope of incoming network connections to only the required networks/hosts.
Blog: How to enable WinRM via Group Policy http://t.co/gDMVV22C1b
RT @alanburchill: Blog: How to enable WinRM via Group Policy http://t.co/gDMVV22C1b
RT @alanburchill: Blog: How to enable WinRM via Group Policy http://t.co/gDMVV22C1b
How to enable WinRM via Group Policy: http://t.co/IQte9w6ivG
RT @alanburchill: Blog: How to enable WinRM via Group Policy http://t.co/gDMVV22C1b
“How to enable WinRM via Group Policy” http://t.co/ib2dNiN7cB
Set the Service to Automatic (Delayed Start) to make sure it starts.
Thank you. And thank you HappySCCM
All the articles on the internet appear to be a copy-paste of one original source, therefore they all have the same two problems. First, they all direct you to Computer > Policies > Windows Components > Windows Remote Management (WinRM) > WinRM Service. when it is actually Computer > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service. Fro some reason, everyone is leaving out “Administrative templates”
Second issue – this is an incomplete solution. With this policy in place, systems are not configured for remote management. You still have to run winrm quickconfig -q which then echoes “created a WinRM listener on http://* to accept WS-Man requests to any IP on this machine.” Once that is done, it works as advertised. However, there appears to be no way to perform this step remotely, much less in bulk/batch. It works flawlessly if actually logged in to the target system, but fails if run in a batch file, or if run using PSEXEC, or even if submitted as an SCCM job. I can find no way to push this to 5000 systems, making the fact that Microsoft is making this a prerequisite for more of its tools and deprecating old functionality that wasn’t WinRM dependent more than a little frustrating.
I was able to issue the winrm quickconfig command remotely with a powershell script using Invoke-WMIMethod.
“winrm quickconfig -q” — worked for me where “winrm quickconfig” alone did not. Thanks.
I’ve checked my own article ( https://www.briantist.com/how-to/powershell-remoting-group-policy/ ) and from what I can tell I’ve got the right group policy paths.
I don’t recall having to do anything else on Windows 2008 R2 / Windows 7 or later operating systems to get it working from there (for earlier OSes I use a separate policy with a startup script).
To piggyback on what Anonymous said above, there is another thing wrong here. The IP Filters do not specify which IP addresses are allowed to connect, they specify which IP addresses the WinRM service binds to.
NO, NO, NO – The IPv4/v6-Filter Field DOES NOT SET the allowed remote administration IPs. It defines a range of addresses the service is allowed to bind to (as clearly stated in the description). To restrict remote access to certain administration IPs configure your firewall rule accordingly.
@Subflow22
How did u do that ?!? 🙂
I have to agree, the statement below is wrong. You use the firewall to restrict who can access remote management from the network not this policy.
“From here you need to specify the IP Address ranges that the service will accept connections from, be cautious if you just add “*†in the field as this can potentially allow incoming connection form all network locations. If possible specify the exact IP ranges that you will be performing the remote management from to reduce the risk of connection coming in from any computer.”
We have recently enabled winrm in a very large environment (40,000+ devices ) via group policy. Our winx64 devices can connect via ps remote session but our 32 bit builds cannot without running Enable-Psremote.
Any ideas on why the policy wouldn’t affect 32bit like it does x64?