Enabling Remoting in a Domain

I’d like to enable PSRemoting on client machines in a domain.

I know Group Policy can be used to enable the WinRM listeners and configure the WinRM service and firewall exceptions. According to the “Secrets of PowerShell Remoting” eBook, group policy does not configure PowerShell Endpoints/Session Configurations. How do you do that then in a domain?

I guess I could write a computer startup PowerShell script that runs Enable-PSRemoting except I suppose I’d have to code something in so it doesn’t try and run it on every single boot, perhaps by creating a registry key or flag file and looking for it first! That seems too messy.

What have other people done to sort this? And do you have any security concerns over using just HTTP listeners (ie not HTTPS) on clients?

Thanks for your thoughts!

Here’s what I’ve done in the past to get this to work in a domain environment:

Start by creating a GPO that modifies the setting ‘Allow remote server management through WinRM.’ It’s located in ‘Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service.’ Ensure the HTTP port, 5985, is open between your local system and the remote one(s). This may require working with your network folks and/or adding a FW exception in Windows (there’s a predefined rule for Windows Remote Management) and this can also be set via GP. HTTP is sufficient in a domain environment as Kerberos is used for authentication. If you want to further lock this down, then look at the other Group Policy settings inside WinRM Service, to disable things like basic authentication. You may also need to enable the WinRM service to start by default: Computer Configuration/Policies/Windows Settings/Security Settings/System Services/Windows Remote Management.

I’m still having issues which I’ve also reported on other forums in the past. I’ve yet to find the underlying cause.

In our test environment, Group Policy enables the WinRM service and listeners but the only PowerShell Endpoint that then gets automatically registered is the Workflow one. For me, this problem occurs on PCs with PowerShell 3 and newer. The PCs are Windows 7 SP1 Pro.

I’ve ended up having to use a Computer Startup PowerShell script in the same GPO that checks for the main endpoint “Microsoft.PowerShell” and if it’s not there, runs “Enable-PSRemoting -Force”. To add insult to injury, that command throws an error if StrictMode is enabled unless you run it twice!

Has anyone else seen this issue with the Endpoints aka Session Configurations being missing and found a fix that’s less of a hack job than this? Thanks!