Upgraded to WMF4, lost Microsoft.Powershell

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.

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.

[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.

There’s not. :slight_smile: 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.

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.

[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 microsoft.powershell.workflow doesn’t exist in v2, either the installer or GPO creates that.

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.

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.

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