Pure Pain: Preinstalled PS Modules - Please Rationalize Them with Package Management Installs
I am trying to update Pester on Windows 2016 to 4.x because the preshipped Pester 3.4.0 emits a note about the depreciation of the -quiet switch when I use the quiet switch. This get's scooped into stdout when executing via AWS SSM remote commands. Version 3.x complains it does not understand "-Show None".
I want to update to 4.x - in which I ran into all the problems documented here: https://github.com/OneGet/oneget/issues/215
But ended up with "Install-module pester -force -SkipPublisherCheck.
So far so bad, but when I go to remove the 3.4.0 version (with admin rights) from: 'c:\program files\windowspowershell\modules\pester\3.4.0' I get errors because only TrustedInstaller has permissions.
If this scenario wasn't horrible enough, putting preinstalled modules under Windows Resource Protection really throws it over the top.
Could someone please make sure that preinstalled modules can be replaced cleanly? Or don't preinstall them?
The issues you have encountered can be frustrating, sorry that is the case for you.
Moving this to Survey to try to gauge the scope of the problem for users generally.
We are somewhat limited by security requirements: what ships with Windows will always be tagged so that nothing can replace it easily unless it is signed by Microsoft. While Pester is part of Windows, it is not owned or developed by Microsoft, so updates delivered via the Gallery cannot be Microsoft signed.
Once the Gallery version is installed on a system, -SkipPublisherCheck is no longer required for future updates. That first experience, however, is bad.
This leaves us with a dilemma: do we stop shipping Pester in with PowerShell in the future, or do we continue to provide the feature set knowing users who update from the Gallery will encounter these issues?
Looking for feedback from as many users as are willing to respond.
Matthew Morrow commented
This is still a problem Got a new windows 10 machine and still Pure Pain.
This guy fixed the problem for me: https://gist.github.com/nohwnd/5c07fe62c861ee563f69c9ee1f7c9688
Then I was able to:
Get-Module Pester -ListAvailable | Uninstall-Module -Force
Maybe we need an CleanUpPester Module....
Phil Isensee commented
I appreciate the value of installing Pester with the OS but if it is not owned my MS, then it shouldn't be installed by Trusted installer nor installed as part of the OS.
My thinking is it has to be one or the other.
Thanks for the feedback, we are listening.
It's both an unfortunate and required limitation that things installed using Trusted Installer are extremely difficult to change by anything else. The approach Trusted Installer uses is built into Windows. There are changes that are happening to how Windows setup works, albeit slowly.
We did discuss not including Pester in the product, but the reported value of having it be present currently outweighs the number of issues that are being reported.
Eric Loveland commented
I think @DarwinJS's idea 1 is most feasible based on @J. Keith Bankston [MSFT]'s feedback. I think it would likely require an additional parameter to Uninstall-Module indicating that we're only intending to uninstall a shipped module, so as to avoid version conflicts if we want to reinstall the same version from the gallery for easier future upgrades.
Olegas Domanskis commented
Having similar issue when trying to use DSC configuration. For example trying to configure xSQLServer it trying to copy over Microsoft.PowerShell.Operation.Validation and Pester modules.
Which is good, since servers are not allowed to access the internet.
But because folders are owned by TrustedInstaller it returns an errors.
It would be good not to have them at the beginning at all.
Personally I feel the overarching goal should be:
"PackageManagement behaves sensibly - at all times - no matter how modules are delivered to the system."
If Microsoft feels strongly enough about integrated testing to include Pester - then other policies or practices should be adjusted to keep PackageManagement sensible - I would even say *especially* for these early encounters of PackageManagement with preinstalled modules.
Implementation Idea 1:
Since PackageManagement is provided (and presumably signed) by Microsoft maybe it just uses TrustedInstaller to manipulate these preinstalled modules? Perhaps if I say "uninstall-module pester -requiredversion 3.4.0" - PackageManagement notices that it is owned by TrustedInstaller and does the magic stuff to use that account.
I have a feeling that getting TrustedInstaller context might be challenging - so maybe this only works for uninstall and it essentially takes ownership assigns permissions and then uninstalls *If I am making the request with elevated admin rights* - so at least I can get that stuff off if I want.
FYI - I was trying to engineer code to take ownership and delete the files - but I reached my pain threshold and gave up.
As a side-note I've just seen too many weird things with module loading to trust leaving the old version there even after the new version is installed.
Implementation Idea 2: Another possible implementation is don't install pester inside the PowerShell MSU (if I understand that is where it is coming from?).
Rather design a powershell script that will pull it down on the first boot after the install within a regular SYSTEM account context. If you don't want the version to be variable, then use -requiredversion.
Maybe the source for the these modules is on local disk (I think this requires PSH 5.1 ?) for actual OS builds.
Implementation Idea 3:
Make the installation of such PowerShell modules an Optional OS feature - ONLY if it allows escaping the TrustedInstaller ownership.
I'd be happy with anything that preserves the defacto expectation of package managers being easy, fluid and sensible rather than what the preinstalled modules experience is now.
Thanks for listening.