I am trying to get queue depth for remote IBM MQ using PowerShell script/commands. Seems it is not working correctly, please help.
{
$myremoteconns = New-WMQQmgrConnDef -Name T.test.TEST.QM1 -Hostname abcd_testhost01 -Port 1111 -Channel T.test.MQMQ.TESTCHN
$qm = Get-WMQQueueManager -Connections $myremoteconns | where {$_.Name -like 'T.test.TEST.QM1'}
Error New-WMQQmgrConnDef the term 'New-WMQQmgrConnDef' is not recognized
Already installed WebSphere MQ - Windows PowerShell Library from below.
http://www-01.ibm.com/support/docview.wss?uid=swg24017698
Thanks
This error means that PowerShell cannot find this cmdlet. You need to check if the module you installed is properly found by PowerShell. Check this first:
Get-Module -ListAvailable
The result will be like:
PS C:\Users\username\PowerShell> get-module -ListAvailable
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 3.0.1 ImportExcel {Import-Html, ConvertFrom-ExcelSheet, PieChart, Import-UPS...}
If you don't find the module on the list you can import it manually using:
Import-Module -Name 'C:\path\to\module.psm1'
In PowerShell (starting at V3) modules should be imported automatically if they are inside on of the path specified in environment variable PSModulePath. You can check its value by using:
$env:PSModulePath
Once you know which folders are included in this variable you can either move the module there or just add another path using
$env:PSModulePath = $env:PSModulePath + ";c:\path\to\module"
This will work for current session. If you want to modify it for all session you can add the line below to PowerShell profile.
More info:
Importing a module
Modifying PSModulePath
PowerShell profiles
Related
I need to move PowerShell Az module from one machine to another offline (both machines have the same windows (10 Pro 1809), .net, powershell (5.1), etc versions)
I can't use either Private PowerShellGet Repositories or MSI installer
I run Save-Module -Name Az -Path 'C:\Users\kag\Documents\ps_modules' -RequiredVersion 3.7.0 -Force on "donor" machine and it gives me 50+ dirs exported:
I copy all to "receiver" machine and running:
Get-ChildItem "C:\Users\kag\Documents\ps_modules\*" -Recurse | Unblock-File
Import-Module -name "C:\Users\kag\Documents\ps_modules\Az" -Verbose
..but getting errors for all dependencies:
Any ideas how to correctly move Az module offline?
Here my comments as answer:
It seems the path you saved the module in C:\Users\kag\Documents\ps_modules is not one of the module paths PowerShell knows of.
You can test which paths are used by PowerShell to find your modules by typing
$env:PSModulePath.split(';')
in the console.
Below is an excerpt from Stefan Stranger's Blog
You can add a temporary path that is available for the current session only:
$env:PSModulePath = $env:PSModulePath + ";C:\Users\kag\Documents\ps_modules"
To make that permanent, you can either add the line above to your PowerShell profile, or manually add it to the registry:
$CurrentValue = [Environment]::GetEnvironmentVariable("PSModulePath", "User")
[Environment]::SetEnvironmentVariable("PSModulePath", $CurrentValue + ";C:\Users\kag\Documents\ps_modules", "User")
use "User" to store this path for the current user only. Use "Machine" to have that path available for all users
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 am trying to install the sysinternals package with powershell, but is instead greeted with tons of warnings. It should be noted that I am following a set of instructions and don't know a lot about this subject yet. Here are the warnings when attempting to run the install-package command:
Install-Package sysinternals
WARNING: NuGet: System.InvalidOperationException: Unable to find version '1.3.5.1' of package 'chocolatey-core.extension'.
WARNING: NuGet: at NuGet.PackageRepositoryHelper.ResolvePackage(IPackageRepository sourceRepository, IPackageRepository
localRepository, IPackageConstraintProvider constraintProvider, String packageId, SemanticVersion version, Boolean
allowPrereleaseVersions)
WARNING: NuGet: at NuGet.PackageManager.InstallPackage(String packageId, SemanticVersion version, Boolean ignoreDependencies,
Boolean allowPrereleaseVersions)
WARNING: NuGet: at NuGet.Commands.InstallCommand.InstallPackage(IFileSystem fileSystem, String packageId, SemanticVersion version)
WARNING: NuGet: at NuGet.Program.Main(String[] args)
WARNING: NuGet: System.InvalidOperationException: Unable to find version '2019.12.19' of package 'sysinternals'.
As for what I've done before this, I've only installed the Chocolatey package provider and updated windows, but maybe I did something wrong? Here are the steps leading up to this:
Set-ExecutionPolicy RemoteSigned
Install-PackageProvider Chocolatey
Install-Module -Name PSWindowsUpdate
Get-WUInstall -Verbose
Get-WUInstall -Install
Any help is much appreciated.
Though you can use Chocolatey and NuGet, PowerShell's package manager is PowerShellGet (well, that uses NuGet by design). So, Choco is not really needed, yet, many still install and use it for the other sources.
If you use PowerShellGet directly, you'll see the same errors.
Find-Module -Name 'SysInternals' -AllVersions |
Format-Table -AutoSize
<#
# Results
PackageManagement\Find-Package : No match was found for the specified search criteria and module name 'SysInternals'. Try Get-PSRepository to see all available registered module
repositories.
At C:\Users\Daniel\Documents\WindowsPowerShell\Modules\PowerShellGet\2.2.3\PSModule.psm1:8873 char:9
+ PackageManagement\Find-Package #PSBoundParameters | Microsoft ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage
#>
Find-Package -Name 'SysInternals' -AllVersions |
Format-Table -AutoSize
<#
# Results
Find-Package : No match was found for the specified search criteria and package name 'SysInternals'. Try Get-PackageSource to see all available registered package sources.
At line:1 char:1
+ Find-Package -Name 'SysInternals' -AllVersions |
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage
#>
Yet, if you do a wildcard search...
Find-Module -Name '*Internals*' |
Format-Table -AutoSize
<#
# Results
Version Name Repository Description
------- ---- ---------- -----------
1.0.34 PoshInternals PSGallery Collection of system internals tools for PowerShell.
4.3 DSInternals PSGallery The DSInternals PowerShell Module exposes several internal features of Active Directory and Azure Active Directory. These include FIDO2 and NGC key aud...
0.2.8 AADInternals PSGallery The AADInternals PowerShell Module utilises several internal features of Azure Active Directory, Office 365, and related admin tools. DISCLAIMER: Funct...
0.1 LCMInternals PSGallery Demo scripts explaining the internals of LCM
#>
Find-Package -Name '*Internals*' |
Format-Table -AutoSize
<#
# Results
Name Version Source Summary
---- ------- ------ -------
PoshInternals 1.0.34 PSGallery Collection of system internals tools for PowerShell.
DSInternals 4.3 PSGallery The DSInternals PowerShell Module exposes several internal features of Active Directory and Azure Active Directory. These incl...
AADInternals 0.2.8 PSGallery The AADInternals PowerShell Module utilises several internal features of Azure Active Directory, Office 365, and related admin...
LCMInternals 0.1 PSGallery Demo scripts explaining the internals of LCM
SilverlightToolkit-Internals-Unofficial 1.0.0 nuget.org The missing part of Microsoft Silverlight Toolkit. The internals DLL. 'System.Windows.Controls.Toolkit.Internals'
AppInternals.Agent.Cloud.Support 10.10.0 nuget.org Configure an Azure Cloud Service solution for AppInternals application performance monitoring.
InternalsVisibleTo.MSBuild 1.0.3 nuget.org Enables declaring 'InternalsVisibleTo' items in a .NET project file, rather than declaring them to an AssemblyInfo.cs file.
Akrual.DDD.Utils.Internals 1.0.8 nuget.org Useful Classes yo use everywhere
Meziantou.MSBuild.InternalsVisibleTo 1.0.1 nuget.org Allow to declare 'InternalsVisibleTo' in the csproj file, rather than declaring them to an AssemblyInfo.cs file.
microServiceBus.InternalService 1.0.0 nuget.org This package creates a stub from which you can create an Internal Service for microServiceBus.com
#>
So, as you can see, there is no such module/package called SysInternals to install.
What you do is just download the zip file from here and unpack and use it as normal.
Sysinternals Suite
https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
I was having the same issue and found the answer here helpful. It seems like something about TLS 1.3 is causing the issue, and the second part of the answer—changing the .Net Framework default TLS version—allowed me to finish my sysinternals install via PowerShell. Then I just deleted the new reg key I had created. I guess I'll just have to wait and see if this is something that comes up again as I continue to learn more and work more with package management in PS.
I wrote a simple PowerShell module. I need to keep more versions of the module. All paths to versions are added to $env:PSModulePath. I'm facing strange problem when importing the module to my session.
This fails:
Import-Module Contoso.PowerShell -RequiredVersion "0.0.2"
Import-Module : The specified module 'Contoso.PowerShell' with version '0.0.2'
was not loaded because no valid module file was found in any module directory.
At line:1 char:1
+ Import-Module Contoso.PowerShell -RequiredVersion "0.0.2"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (Contoso.PowerShell:String) [Import-Module], FileNotFoundException
+ FullyQualifiedErrorId : Modules_ModuleWithVersionNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand
And now the strange thing - the module with the "0.0.2" version exists. I can successfully list it (with Get-Module -ListAvailable). I can even import it and work with it, but the only way how to do it is this:
Get-Module Contoso.PowerShell -ListAvailable |
? { $_.Version -eq "0.0.2" } |
Import-Module
Everything works like a charm then. The question is: WHY? I'd like to be able to import the module with the first simple command.
EDIT:
Here is how I store the versions of the module:
Get-Module Contoso.PowerShell -ListAvailable
Directory: C:\Program Files\WindowsPowerShell\Modules\Contoso.PowerShell\Contoso.PowerShell.0.0.1
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0.1 Contoso.PowerShell
Directory: C:\Program Files\WindowsPowerShell\Modules\Contoso.PowerShell\Contoso.PowerShell.0.0.2
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0.2 Contoso.PowerShell
And sorry for confusion - I do NOT have paths to each version in the PSModulePath environment variable.
The reason Import-Module works is because it uses a different parameter set; one where it accepts one or more [PSModuleInfo] objects, which are what Get-Module returns.
Likely, it uses the work already done by Get-Module to determine which file to load.
The next question then is "why doesn't Import-Module find the version the same way Get-Module does?" and the answer to that is "I don't know."
While they should be consistent in any case, a possible cause for trouble is your directly structure. How are you storing multiple versions?
It looks to me like your module paths are incorrect.
Your structure should be:
Contoso.PowerShell\0.0.2
Contoso.PowerShell\0.0.3
etc.
The module files go directly in the version number folder, and it shouldn't additionally have the name inside it.
You can see this structure by using Install-Module to install one from a repository and taking a look at how it handles it.
I recently installed Windows 10, which includes V5 of PowerShell, or 5.1.14393.206 to be exact ($PSVersionTable.PSVersion).
On new computers I install PSReadline. However, Windows 10 comes with it already installed.
My question is, how is PSReadline loading automatically, when there is no profile to import it, (or call a command from it)?
As proof, I ran this code:
$PROFILE | Get-Member -MemberType NoteProperty | % {
$path = $PROFILE.$($_.Name);
$exists = Test-Path $path;
[pscustomobject]#{ Path = $path; Exists = $exists }
}
To get this:
Path Exists
---- ------
C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 False
C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 False
C:\Users\tahir\Documents\WindowsPowerShell\profile.ps1 False
C:\Users\tahir\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 False
I have gone through all of https://stackoverflow.com/a/23942543/288393:
No call to Import-Module for PSReadline is made because there are no profiles to call it.
No commands within PSReadline module are made because, as before, there are no profiles to call it.
Can someone explain this behavior?
There is special code in the console host to load PSReadline if the process is interactive. You can see the code here.
PSReadline is located in a pre-defined module folder C:\Program Files\WindowsPowerShell\Modules, because it's here PowerShell's automatic cmdlet discovery and module loading process will pick the module up and load it when any functions within it are called. That process added in PS v3.