Please feel free to provide feedback or file bugs here.

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?

1 vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    DarwinJSDarwinJS shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    survey  ·  J. Keith Bankston [MSFT]AdminJ. Keith Bankston [MSFT] (Admin, Windows Server) responded  · 

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

    1 comment

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • DarwinJSDarwinJS commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base