January 1, 2012 at 12:00 am #6127
by Sentri at 2013-04-15 13:37:45
I recently moved to a new job and was tasked with doing something that I've done before: enabling GPO for Powershell Remoting. In an effort to make this concise, I made all of the necessary changes to the Domain GPO Firewall, enabled WinRM service and set it to auto, & enabled all listeners– I still could not remote machines using Powershell; I received this error:
service cannot process the request. Cannot find the Microsoft.PowerShell session configuration in the WSMan: drive on
the MACHINENAME computer. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (MACHINENAME:String) , PSRemotingTransportException
+ FullyQualifiedErrorId : InvalidResourceUri,PSSessionStateBroken
I remedied this issue by running this: Register-PSSessionConfiguration -Name Microsoft.PowerShell -Force
I can now remote mahcines using Powershell; however, I do have two questions:
1. What exactly is Register-PSSessionConfiguration -Name Microsoft.PowerShell -Force doing?
2. Why is it that when I run winrm quickconfig I get an error message about being unable to check firewall(despite the fact that everything works now, including commands like winrm enumerate winrm/config/listener)?
by JeffH at 2013-04-15 17:05:19
PowerShell remoting works by setting up a WinRM endpoint listening on 5985 (by default). In a nutshell when you run a remote PowerShell command, your computer connects to the remote computer using WinRM and passes the command to the remote endpoint. I'm simplifying a little bit but basically you need to allow your computer to talk to PowerShell on the remote computers. Look at the about_remote* help topics.
by Sentri at 2013-04-16 06:39:47
Thanks for the response. I'm aware of that aspect of Powershell remoting, but I was curious about the issue I had with having to run this: Register-PSSessionConfiguration -Name Microsoft.PowerShell -Force to register a Powershell session and why that wasn't activated with enable-psremoting(like it should be, as far as I know) or why I had to do it in the first place. Since posting this message, I did find that the $PSSessionConfigurationName variable is set in the local schema somewhere? I've never run into that issue when setting up Powershell for remote access before.
by Sentri at 2013-04-16 08:16:03
I guess my question is, what exactly is this cmdlet doing: Register-PSSessionConfiguration -Name Microsoft.PowerShell -Force
by JeffH at 2013-04-16 10:10:14
I don't know in what order you configured things so it is really hard to say why you had the issues you did. Register-PSSessionConfiguration is setting the powerShell endpoint so that remoting will work. Again, I've never had to do this because Enable-PSremoting handles this.
by Sentri at 2013-04-16 14:04:24
Yeah that's why I'm sort of puzzled by it, since enable-psremoting should handle it. Previously, at my last job, I set Domain GPO for Powershell remoting, but didn't run into this issue with registration. I'm working around this by setting all of the necessary settings for enabling WinRM in Domain GPO, as well as running a scheduled task that registers the machines, via the registration cmdlet.
by DonJ at 2013-04-17 10:37:42
You might read through "Secrets of PowerShell Remoting" (PowerShellBooks.com; free) – it covers what the Enable-PSRemoting does in detail, and outlines all the GPO steps needed to replicate that. Typically if Enable-PSRemoting doesn't create that default endpoint it's because there was an underlying configuration or permissions issue that prevented it from doing so.
by Sentri at 2013-04-17 14:56:45
That makes sense– thanks, Don and Jeff! I will have to check out "Secrets of Powershell Remoting" tonight. For now, I have all of the settings in GPO set and a script that runs daily(for subsequent machines that may come into the domain), that runs the registration cmdlet. This is the implementation I will have to use for now, until I find – what probably is – the small, underlying issue here.
Also worth noting: Machines set to take this policy that I've made can be accessed remotely via Powershell, but if you run a winrm quickconfig, it throws that it can't check the Firewall. Funkiness. I turned off something server side on an AV program that this place uses that might have been causing the conflict– not sure. For now, Powershell remoting does work given this policy, and I will have to work out the minor kinks, going forward.
by Sentri at 2013-04-18 14:06:07
**UPDATE** I actually think I may have realized the problem. Despite the fact that my Domain GPO Firewall is turned on and the exceptions I've made work, I never configured the Domain Firewall service– it's running on the clients in this test environment, but it's running as the local service. I'm guessing that since all of the settings that I have for WinRM are coming down from the domain, EXCEPT the Firewall service, that maybe this is what's causing Powershell confusion. Interesting that I can still get Powershell to work if I explicitly call the registration cmdlet, regardless though. I made the change on the domain GPO a little while ago, and tomorrow when I get in, I'll reboot the machines affected and see where I'm at.
by Sentri at 2013-04-18 14:30:07
Just tested it out after the change– same thing. Worst case, I leave my current policy as is and it works this way.. just really bizarre.
by Sentri at 2013-04-23 13:43:19
I guess I could ask my main question in one line, rather than a paragraph: would there be any particular reason that I need to run register-pssessionconfiguration, even after I've made all of the necessary configuration changes to GPO, for Powershell remoting to work?
by Sentri at 2013-04-25 11:34:37
I noticed something.. when I turned the Firewall and Firewall service off and run winrm qc, it comes back fine. When I flip it on, that's when it generates "unable to contact the firewall." At this point, would it make sense to just recreate a new policy from scratch? Do I really need to follow a particular order when configuring policy for Powershell remoting, i.e. enable the service and set it to automatic, configure listeners, then configure firewall? If I do that out of order(which I believe I did with this current policy that seems funky), will all of this not work properly, the way I've been describing all of this?
You must be logged in to reply to this topic.