March 30, 2015 at 11:27 am #23789
I have a bunch of Windows 7 clients (PowerShell v2, PSRemoting enabled), which recently upgraded to WMF4. It looks like they've lost Microsoft.Powershell on the way.
Windows PowerShell Copyright (C) 2014 Microsoft Corporation. All rights reserved. PS C:\Windows\system32> get-pssessionconfiguration Name : microsoft.powershell.workflow PSVersion : 4.0 StartupScript : RunAsUser : Permission : BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
PS C:\> etsn WIN7BOX etsn : Connecting to remote server WIN7BOX failed with the following error message : The WS-Management cannot process the request. Cannot find the Microsoft.PowerShell session configuration in the WSMan: drive..
I do have a GPO that enables PSRemoting, and it does work on all other boxes (either shipped with Powershell v2 or v4). This ..thing only happens with the v2->v4 "upgradees".
Is there a more robust fix for this other than psexec-ing to each box and running Enable-PSRemoting? – This does fix it (puts Microsoft.Powershell back in there), but it's as desirable as a frog in a blender.
March 30, 2015 at 11:40 am #23791
What's in your GPO? Ideally, it should include a startup script which runs powershell.exe -Command Enable-PSRemoting -Force . That way you don't have to do this manually.
March 30, 2015 at 12:24 pm #23795
[x] Allow Remote Server management through WinRM [x] Windows Firewall: inbound rule for TCP/5985 [x] Start WinRM service at boot
This works perfectly fine for everything but clients i upgrade to WMF4.
Sure, i can do startup scripts, but there must be a more elegant way... in.
March 30, 2015 at 12:28 pm #23796
There's not. 🙂 And those GPO settings unfortunately do not create the PowerShell remoting endpoints, which is why you're in the situation you've currently got. Something has to run the Enable-PSRemoting command, and the only way I know of to get Group Policy to do that properly is with a startup script.
March 30, 2015 at 12:29 pm #23797
Name : microsoft.powershell.workflow
This one gets created so my wild guess is that it can't overwrite the v2 endpoint for some reason.
I'll try to make the MSU WMF4 installer as verbose as possible and then take a look in the log.
March 30, 2015 at 12:32 pm #23798
[blockquote]And those GPO settings unfortunately do not create the PowerShell remoting endpoints, which is why you're in the situation you've currently got[/blockquote]
But then, how do i get PSRemoting for computers that i unbox and just join to the domain? I never run Enable-PSRemoting on those.
I'm pretty sure [b]microsoft.powershell.workflow[/b] doesn't exist in v2, either the installer or GPO creates that.
March 30, 2015 at 12:41 pm #23799
Beats me. PSRemoting isn't enabled by default on any OS prior to Server 2012 R2. Could be that you've got a Windows image that has Enable-PSRemoting being run during Sysprep's SetupComplete script, or something along those lines.
March 30, 2015 at 1:04 pm #23802
No, i'm sure it's not that. These are Dell Latitude E6xxx, vanilla. If i don't have my PSRemoting policy linked on the OU the computer sits in, i don't get any remoting, as expected. It's either a bug or i'm missing a bunch of KBs. Or i'm doing it wrong.
March 30, 2015 at 10:10 pm #23804
Maybe it's an idea to switch on PowerShell diagnostics and see what the logs are saying
Import-Module PSDiagnostics Enable-PsWsmanCombinedTrace
Run a remoting command, and then take a look at the event logs Admin and Operational under Applications and Service Logs/Microsoft/Windows/PowerShell/Windows Remote Management
You must be logged in to reply to this topic.