I'm new to powershell.I'm facing an error while working on an existing script.
In C:/Scripts I have 3 files . One .ps1 file and 2 .psm1 file.
ps1 file Name : RunScript.ps1
This imports .psm1 files like below.
$modules = #(
"$PsscriptRoot\Modules\Module1.psm1",
"$PsscriptRoot\Modules\Module2.psm1"
)
foreach ($module in $modules) {
if (-not $(Get-Module $module)) {
Import-Module $module -Force -WarningAction SilentlyContinue
}
}
This above code is giving me error as below
Get-Module : Running the Get-Module cmdlet without ListAvailable
parameter is not supported for module names that include a path. Name
parameter has this element 'C:\Scripts\Modules\Module1.psm1' which
resolves to a path. Update the Name parameter to not have path
elements, and then try again.
It is expecting to not give path of the file. But how do I do Get-Module in this scenario. Any help is very helpful.Thanks.
Get-Module returns modules imported into the current session or modules installed that are available for you to import. You should install your module then it will be available with the get-module cmdlet by using the name of your module.
I'm not quite sure what you're trying to do with your script? You only want to import it if its not already imported?
I would have added this as a comment but I cant yet...
Related
I am running into some issues with loading a PSM1 file. The PSM1 is always in the same folder as the PS1, but that folder can change. It works if I use a literal path like this...
Using module '\\Mac\iCloud Drive\Px Tools 4.#\Dev 4.0\#Spikes\Windows7\library.psm1'
But that's useless since the code could be installed anywhere. And the code is signed, so it can't change.
It also doesn't work to use the new (in PS3.0) $PSScriptRoot automatic variable...
Using module "$PSScriptRoot\library.psm1"
Nor does a relative path or simple file name, as in...
Using module ".\library.psm1"
or...
Using module "library.psm1"
What am I missing, other than perhaps it's time to call it a day?
Also, note that the library contains classes, so other module loading options like Import-Module don't work. This has me wondering if perhaps classes are better supported in a later version, and I should really be targeting PS 6.0, rather than 5.1?
Looking for more info on your problem, I came around this blog post. It says relative paths work, so have you tried using relative path with single quotes or without quotes?
Since values inside double-quotes get evaluated before passing them to the cmdlet, using them might not work.
you should run import-module first.
in PS1, I have add code to call import-module
like this:
ForEach($_ in Get-ChildItem "$env:TEMP\*.psm1") {
$checkModuleName = $_.Name -replace ".psm1"
$importModule = $_.Name
if (Get-Module $checkModuleName) {
Write-Host "Update Module $importModule" -ForegroundColor Green
Remove-Module $checkModuleName
Import-Module "$env:TEMP\$importModule"
}
else {
Write-Host "Import Module $importModule" -ForegroundColor Green
Import-Module "$env:TEMP\$importModule"
}
}
when import done, I can used all module.
Looking for some help with a script. I have tried and failed. I am not really advanced in powershell.
importing dlls is new for me. Any help is appreciated.
I want to use powershell to import the wlanapi.dll and use micrsoft native wifi functions to disable wireless background scanning, and enfore streaming mode.
The script should do this on execute. That way I can run it, or set it in a start up script.
https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/nf-wlanapi-wlansetinterface?redirectedfrom=MSDN
Functions I am wanting to use:
wlan_intf_opcode_background_scan_enabled
wlan_intf_opcode_media_streaming_mode
Import is something you do via the PSModule paths where your modules or DLLs live.
You must tell PowerShell where the DLL is, no different than you'd have to if you loaded a module (.psm1 file with or without a manifest) of which you did not install to one of the defined PowerShell module paths.
You can use Add-Type...
Add-Type -Path $UncToCustomDll
... yet also, you can also use reflection:
$customDLL = 'UncToYourDLL'
See also Lee Holmes article on the topic here:
Load a Custom DLL from PowerShell
If you try to import and it's not in a know location, you get this.
Import-Module SomeNewCustomOr3rdP.dll
Import-Module : The specified module 'SomeNewCustomOr3rdP.dll' was not loaded because no valid module file was found in any module directory.
Of course, that error is pretty specific. It has no idea where to find it because that name does not match a module name.
So, this ...
Import-Module 'c:\users\mj\desktop\SomeNewCustomOr3rdP.dll'
Or create a folder of the same basename as the DLL in the PSModulePath, copy the DLL to the that named folder and use import as normal
C:\Users\<username>\Documents\WindowsPowerShell\Modules\SomeNewCustomOr3rdP\SomeNewCustomOr3rdP.dll'
Then this...
Import-Module SomeNewCustomOr3rdP
... should work as expected. All-in-all, Add-Type, Import-Module, and Reflection.Assembly::LoadFile($customDll), all accomplish the same thing, grant you access to the resource you specified.
If you are using a 3rdP DLL/Module, all this has to be done manually. If you are using published modules/packages that are in the MS powershellgallery.com, then this:
# Find all modules with wlan in the name
Find-Module -Name '*wlan*' |
Format-Table -AutoSize
# find all packages with wlan in the name
Find-Package -Name '*wlan*' |
Format-Table -AutoSize
# Get the detail on wlanapi specifically
Find-Package -Name 'wlanapi'
# Download and save a module or package
Find-Package -Name 'wlanapi' |
Save-Package -Path "$env:USERPROFILE\Documents\WindowsPowerShell\Modules"
Install-Package -Name 'wlanapi' -Force
Import-Module -Name wlanapi
I created a PowerShell module MyUtil.psm1 and a manifest file MyUtil.psd1 for it. In the psd1 file it has the prefix defined to prevent name conflicts for exported functions:
DefaultCommandPrefix = 'MyToolbox'
This way, after running Import-Module .\MyUtil.psd1, a function like Get-Command in the psm1 file will be Get-MyToolboxCommand, everything is fine. But if someone runs Import-Module .\MyUtil.psm1 to import the psm1 file directly, the psd1 file is simply not used and the prefix I want won't be applied.
If I want to prevent this (importing MyUtil.psm1 directly), is there a way to ONLY allow importing the corresponding psd1 manifest file instead of the psm1 file? Or a programmatic way to detect that this module was not imported through psd1 so I can warn the user to use psd1?
Ok, this is a bit annoying, but it works. You can use the Export-ModuleMember cmdlet with no args to stop the psm1 from exporting anything, but you need to send a value from the psd1 to the psm1 during the import. That way we know when we're being called with the psd1. So first off, add a value to the PrivateData hashtable in your PSD:
PrivateData = #{
FromPSD = $true
PSData = #{
Then you need to access it in the psm1 file. You can in a function, but not inline, so we have to stick it into a function.
function Get-PD
{
[CmdletBinding()]
$MyInvocation.MyCommand.Module.PrivateData
}
(I totally stole this from this SO answer Accessing PrivateData during Import-Module).
Then you wrap it all up by calling this code in the module which will get run as the module is loaded.
$MyPD = Get-PD
if($MyPD.Count -eq 0)
{
Export-ModuleMember
}
Now, if you don't want this pesky extra function to be referenced when the module is loaded, you'll need to populate the FunctionsToExport in the psd1 file with the list of functions you want the users to have access to.
You can use: #Requires
For example:
Require that Hyper-V (version 1.1 or greater) is installed.
#Requires -Modules #{ ModuleName="Hyper-V"; ModuleVersion="1.1" }
Requires that Hyper-V (only version 1.1) is installed.
#Requires -Modules #{ ModuleName="Hyper-V"; RequiredVersion="1.1" }
Requires that any version of PSScheduledJob and PSWorkflow, is installed.
#Requires -Modules PSWorkflow, PSScheduledJob
About Requires
Im using PowerShell 4 on Windows Server 2012 R2.
A specific module, WebAdministration, does not get auto loaded when calling a Cmdlet that comes from this module. All other modules I have tried auto load successfully. I can load this module manually using Import-Module and it behaves as expected.
The PSModulePath environment variable contains the path with the module. Other modules from this path auto load.
The module is not custom. It is a built in IIS feature. The feature is enabled.
AutoLoading is enabled. $PSModuleAutoLoadingPreference is set to "All"
Get-Command "Get-WebBinding" doesn't work, but Get-Command | where {$_.Name -eq "Get-WebBinding"} does.
Get-Module -ListAvailable | where { $_.Name -eq "WebAdministration"} returns the module with the correct path.
PSModulePath = %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\
WebAdministration Module Path = C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WebAdministration
Output from simple test
PS C:\Users\Administrator> $PSModuleAutoLoadingPreference = "All"
PS C:\Users\Administrator> Get-WebBinding
Get-WebBinding : The term 'Get-WebBinding' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling
of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-WebBinding
+ ~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-WebBinding:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
PS C:\Users\Administrator> Import-Module WebAdministration
PS C:\Users\Administrator> Get-WebBinding
protocol bindingInformation sslFlags
-------- ------------------ --------
http *:8082: 0
http *:8081: 0
Any suggestions on why the auto loading isn't working would be greatly appreciated. Thanks!
Here's how I chose to load modules when I start up ISE each time. This gives me the option to load certain modules. I know this isn't what you asked for, but this does automatically load modules, and be sure to note how these modules are called.
Create the following file:
Path: C:\Users\<username>\Documents\WindowsPowershell
File: Microsoft.PowerShellISE_profileX.PS1
In the file, I use this code, but modify as needed:
$a = new-object -comobject wscript.shell
$intAnswer = $a.popup("Connect to Office 365?",0,"Office 365",4)
if ($intAnswer -eq 6){
#YES - Go to Cloud
#$a.popup("You answered yes.")
Set-Location H:\sandbox
#. .\Start3.ps1
. .\Auto-Connector.ps1
. .\Refresh-PSSession.ps1
. .\ScriptLoaders.ps1
. .\ESDSCRIPTS3.ps1
}else{
Set-Location H:\sandbox
Import-Module ActiveDirectory
}
I would consider using the #Requires statement at the top of the script file after you have imported it for the profile that the script will be running under. The script will likely not run unless it can find the module that the script requires. You then do not need to use the 'import-module' cmdlet as its already handled for you. You can read more about the requires statements here.
for example:
#Requires -Modules WebAdministration
Try reinstalling the module to see if that makes a difference.
If that doesn't work, while it's annoying that the autoload isn't functioning, you can import the module before use and expect it to work.
Import-Module WebAdministration
Get-WebBinding
Or if you need a one-liner:
Import-Module WebAdministration; Get-WebBinding
The only real clue I can find on why this may not work is that modules using providers may not autoload. WebAdministration provides the IIS: PSDrive. However, as I've indicated in a previous comment, I am able to autoload the WebAdministration module on WS 2016 with PS 5.1 installed, which goes against this statement. My hypothesis is this limitation might not be relevant in PS 5.1+, but I can't say for certain since I don't have a PS 4.0 env to test with.
I'd like to be able to set LogPipelineExecutionDetails = $True (from about_Eventlogs) in the .psm1 file of my module but when I run Get-Module with the module name it doesn't return anything. Is there another way to get the PSModuleInfo object for the current module?
Try this:
get-module -list | Select Name, LogPipelineExecutionDetails
Edit:
To alter the property it seems that you have to load the module first, even in 4.0. Loading the module also seems to be a requirement to get the -Name parameter of Get-Module to work.
Import-Module AppLocker
(Get-Module AppLocker).LogPipelineExecutionDetails = $True
Get-Module AppLocker | select name,logpipelineexecutiondetails
This worked for me