PowerTip: Import a PowerShell Module from a Shared Location

Summary: Learn how to import a Windows PowerShell module from a shared location.

Hey, Scripting Guy! Question I have a module that will run on multiple servers, and I want to be able to access it from a single location. How can I import a Windows PowerShell module from a central location?

                             Hey, Scripting Guy! Answer Use the Import-Module cmdlet and specify the complete path to the folder containing the module. You can then use cmdlets from the module as if it were installed locally. 

                                                    Import-Module \\dc1\Share\PSWindowsUpdate


Comments (5)

  1. Gene Laisne says:

    Ooo… What if you created a module that updated all your modules from a central Server!

  2. Ed Wilson says:

    @Gene Laisne I believe you could do that … it would be cool!

  3. sam says:

    Not that easy though. What if your module has a dependency, say on another .NET library also sitting on a shared network?

  4. JV says:

    @Sam  Fortunately that is not possible.  Net libraries must be installed locally.  They cannot reside on the network.  The PosH module file .psm1 can reside anywhere and can have depende4ncies on other modules.

  5. Brett Peirce says:

    One thing to keep in mind is that often network shares are easier to access for anyone – not just the admin running this script on multiple servers

    Modifications to this particular network-hosted module can then affect any computer by importing them. Traditionally, the majority of modules have a set of functions that can then be used later by the user that imports them, but technically, one can put executable code for anything that PowerShell can do into such a file and this code will run on import. Since PowerShell, especially executed with elevated system privileges, can do nearly anything, it might be wise to use caution when importing from a network location, where a local copy is slightly less prone to tampering.

    Obviously you can mitigate this risk somewhat by controlling access to the network share, and I’d guess you can make sure that you have an ExecutionPolicy set to RemoteSigned or AllSigned, but I might also suggest that for periodic importing (not as useful for a one-time run of the script), you might have a local module on each server that is responsible for checking the file in some way – it could be an expected length limit, dirty word (or dirty command) search, checking to make sure that there are only function definitions and no code that will execute immediately…

    All of these, I think, can be beaten with the right access and resources, but there’s no need to beat them if they’re not even implemented…