How can I run psd1 and psm1 files in powershell?

I tried .\script.psd1 and .\script.psm1. How can I run it? Yes, I already set the execution policy and I want to run the script from a directory somewhere on my desktop or elsewhere.

4 Answers

Import-Module ./path/filename.psm1

It's that simple.

In the simplest case, just put all your functions into a PSM1 file and import it like that.

PSD1 files are manifests and only matter when you make a module "ModuleName" in a folder named "ModuleName" with the 2 files "modulename.psd1" and "modulename.psm1". The PSD1 manifest can be created using the New-ModuleManifest cmdlet. It's for stuff like version number, copyright year, dependancies, etc.

This is really basic PowerShell stuff.

You should not need to mess with a psd1 file. To load and use a module (psm1, dll), it should be installed/saved module(s) in your default path in a same-named folder...

$env:PSModulePath -split ';'
# Results
<#
C:\Users\Postanote\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
C:\Program Files\Microsoft Message Analyzer\PowerShell\
C:\Program Files (x86)\Microsoft SQL Server\150\Tools\PowerShell\Modules\
C:\Program Files (x86)\AWS Tools\PowerShell\
#>

...for it to be found and autoloaded.

Note: There really is no concept of installing a module (as you would with an exe or msi installer), as all that...

# Get specifics for a module, cmdlet, or function
(Get-Command -Name Install-Module).Parameters
(Get-Command -Name Install-Module).Parameters.Keys
Get-help -Name Install-Module -Examples
Get-help -Name Install-Module -Full
Get-help -Name Install-Module -Online

...command really does is download the module from the Microsoft PowerShellGallery.com or other defined repository (say your internal one), and store that in profile path or path you tell it to.

If they are not in the known, $env:PSModulePath, then you have to manually load/Import them from where ever they are.

If it is, however, just a file not in a same-named folder, then you have to use dot-sourcing to load and use the code in it.

You can load/Import/Dot-Source and run modules (.ps1, .psm1, dlls) files from any location where they are stored and you have permissions to read.

You do this by loading (Importing or Dot-Sourcing) them manually via your profile(s)...

Microsoft.PowerShell_profile.ps1
Microsoft.PowerShellISE_profile.ps1
Microsoft.VSCode_profile.ps1

...or only per session, via your script or session.

You can use modules deployed on other systems, using PowerShell Remoting, either explicitly or implicitly. This is is well-documented all over the web. Just search for it. In an Explicit/Implicit remote session, the cmdlets from a module are proxied to your session for use, but never saved there. They are only available in your session. Close the sessions, the cmdlets or code in them are not usable.

'import-module remote file share'

'powershell dot-cource psm1 file'

Use PowerShell Active Directory Cmdlets Without Installing Any Software

Update, base on your recent post.

So, this was not a module problem at all. It's corporate policy enforcement, where they have the host machine ExcutionPolciy set to prevent you from running scripts, modules (and thus their code) from untrusted, or remote resources period.

PowerShell can be started and set the EP to whatever you choose and that does not change how the host EP is set.

You can create your own shortcut to PowerShell, pin that to your taskbar, set the EP to whatever you choose, and use the correct EP policy type. User or session. Which is all you are doing here. From that point start PowerShell using the shortcut, not the default ones.

The EP was never designed to be a security boundary. It's there to prevent mistakes and randomly running untrusted, unsigned scripts/modules, etc.

Local scripts or anything you run in your current session will work the way you are doing it. So, this not really a workaround, for PS, it's an 'I want to run my PowerShell stuff regardless of what the host EP is set for'.

You have to be willing to take complete responsibility for doing that. For if you mess something up, well, you know...

This is no trick/workaround it's by design. The ways to run PowerShell regardless of the host EP setting is a well-documented thing, from Microsoft (via the Powershell Help files) and this old article on the topic.

15 Ways to Bypass the PowerShell Execution Policy

You also did not need to do this either...

$currentDirectory = Get-Location
Import-Module $currentDirectory\yourModule

... you can Import via UNC. It's shown specifically in the PowerShell help files.

<#
Example 12: Import using a fully qualified path
This example imports a specific version of a module using the fully qualified path.
#>
Import-Module -Name 'C:\Program Files\PowerShell\Modules\PowerShellGet\2.2.1\PowerShellGet.psd1

You also, should not need to be admin to do this, well, depending on what module you are using and what you are doing with it. Say, Exchange, ADDS, etc.

.psm1 files contain main source code for a powershell module and .psd1 manifest data. You have to install them. First place the .psd1 and .psm1 files in your $PSModulePath. Then run Import-module module_name. Then the module will be installed and imported.

I only found a workaround and no solution yet. Just open an admin powershell, go to the directory with your module and type:

#Policy automatically resets if you close the ps window.
#Policy is only active in this ps instance.
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
$currentDirectory = Get-Location
Import-Module $currentDirectory\yourModule
#Do stuff...
yourNewCommandLets
...
Remove-Module yourModule

It is just for temporary modules you don't want to permanently "run".