BUG: WMF5 RTM $PSModulePath
After installation of the WMF5 RTM the $PSmodulePath is RESET to default.
Update the $PSModulePath instead of resetting it.
If additional modules are installed these are not available after installation of WMF5 RTM.
WorkAround : Store your system variable PSModulePath before installing WMF5
After installation of WMF5 restore your original PSModulePath
My apologies for forgetting to close this one when we fixed. This was corrected in WMF 5 RTM back in February.
Thank you for your understanding,
Patrik Ehringer commented
I guess this could get marked as 'Completed' by now?
Juho Lehto commented
I wonder what problems the RTM truly has because re-release is taking really long. My team really needs the new Copy-Item cmdlet in v5 with support for copying files to and from remote sessions. Otherwise we could use v4 just fine.
Aaron Stainback commented
I'm trying to setup a new VS2012 R2 server and I am aware of this issue, can you provide some unofficial download of the old version? I'm okay with doing the work around for now.
Maximo Trinidad commented
Big question!! What about Windows 10 November update that's supposed to match the WMF 5.0 RTM. There's not mention about how this impact Windows 10 clients in the posted blog.
Can you provide any insight on it?
@postanote That's terrible and I sympathise with you.
If I was hit with this bug, rather than try to work it out by hand, I'd put together a script to recurse all the local drives and folders (excluding user paths) to identify where modules and snappins are located; prompt the user and save the new system path with those added. You'd have to at least review them though to make sure no malware were accidentally added.
If I had made a mistake like this it's the kind of tool I would provide. But seeing as it's unlikely we'll get one then you could write one yourself and share it.
We have heard your feedback and due to this bug, the PowerShell Team has removed WMF 5.0 RTM from the Download Center. We will deliver a revised WMF package as soon as the issue can be isolated, corrected, and validated. Further details are available on the PowerShell Blog at http://aka.ms/pshblog
Maximo Trinidad commented
This issue has been happening for some time. It's specially noticeable when trying to use the SQL Server SQLPS module which you always ended up adding the module path to the "PSModulePath" variable.
A possible recommendation for future version to have all application install their PS modules to a general location surch as: C:\Program Files (x86)\WindowsPowerShell\Modules and/or C:\Program Files\WindowsPowerShell\Modules.
I think this would make it easier to manage. Of course, all server applications product team should agree on it.
Joel "Jaykul" Bennett commented
@postanote: it's just an Environment variable. You can set it in your profile script, or set it system-wide in the Environment Variables control panel.
E.g. Hit Win+Break and in the "Advanced System Settings" (aka "System Properties" control panel, Advanced tab) you click "Environment Variables" and edit (or create) the System variable named "PSModulePath" ... and add the paths where your modules are installed.
This really should have been in the announcement.
I got hit by this and there was no info on this until this post.
I post a few posts that have yet to show up at all about this issue here: http://blogs.msdn.com/b/powershell/archive/2015/12/16/windows-management-framework-wmf-5-0-rtm-is-now-available.aspx
So, now, what are the folks, like me, who installed this and now, to do, where no previously installed / configured modules - customizations work.
So, what are we to do to get our path back, other installing everything or hacking at the path manually from scratch?
Wessel van Sandwijk commented