I'm trying to run Pester tests on a Windows 7 machine. I followed the instructions from here, and I also installed PSGet and executed Install-Module Pester.
This works on both the Windows 7 machines I have. I can run the pester tests from an elevated PowerShell console.
I have a .cmd file which runs the Pester tests, but I'm unable to run it from an elevated command prompt. This works on one Windows 7 machine, but it doesn't work on another one.
I followed the same instructions to install Pester on both the machines. Please suggest what I might be missing.
On the machine that 'doesn't work':
When I run the Pester script from PowerShell, the Invoke-Pester works and the script runs as expected. But, when I try to run the .cmd file which points to the pester scripts, I get an error saying Invoke-Pester is not recognized as a cmdlet, function; which means, as far as I understood, Pester is not working from the command prompt.
On the machine that 'works':
I am able to run the Pester script from both PowerShell and command prompt windows. The script runs as expected.
I found that the particular laptop I was working on, had some permission issues (corporate issues), and I couldn't get the Pester scripts working from the command prompt.
Anyway, I moved on to another Windows 7 laptop and installed Pester using the following instructions:
Download PsGet.psm1 from https://github.com/psget/psget/
Copy PsGet.psm1 to your modules folder (e.g. Modules\PsGet)
Start a new PowerShell session and import the Pester module using the commands below:
Get-Module -ListAvailable -Name Pester
Import-Module PsGet
Install-Module PsGet
Import-Module Pester.psm1
Install-Module Pester
Check the execution policy set on the computer with: Get-ExecutionPolicy. The output should be Unrestricted. Otherwise, run: Set-ExecutionPolicy Unrestricted
Related
I'm trying to schedule a powershell script to run on a server. I used $env:PSModulePath and one of the powershell locations is c:\windows\system32\windowsPowerShell\v1.0\Modules. When I look in that location, there is no Powershell.exe there. I wanted to use that for the Application name in the system scheduler. How can I verify that Powershell.exe is there? I also wanted to find which version each one is for all of the powershell versions seen with $env command above to verify which would be the 5.1 version that I tested on my computer with.
env:PSModulePath
c:\windows\system32\windowsPowerShell\v1.0\Modules is the Modules directory
$psHome returns the .exe location
I'm writing a PowerShell script to run a Pester test.
. .\..\LoadModule.ps1
. .\..\..\SomethingElse\LoadModule.ps1
Import-Module Pester -MinimumVersion 4.0.0
Invoke-Pester -Script .\Test\
However Pester runs before output from the two dot-sourced scripts has finished, and I'm afraid that the modules they're supposed to load have not fully loaded which could lead to inaccurate test results.
The ImportModule.ps1 scripts search for a specific .NET .dll and then Import-Module it.
I've tried putting an & in front of the Invoke-Pester command, but it didn't help.
So, how do I make PowerShell wait for the dot-sourced scripts before running Pester?
I am calling the below script in my post build configurations:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile
-ExecutionPolicy RemoteSigned -file "\Sclddev8\tfs\Scripts\slack-notice.ps1" -Verb RunAs;
However, I keep getting this error:
Send-SlackMessage : The term 'Send-SlackMessage' is not recognized as the name
But I have installed this module in my environment and if I open a PowerShell console or run the file outside of this build process, works without issue.
When you install a Powershell module, you are technically importing the module from your profile every time you open a new Powershell window. By running Powershell with the "-NoProfile" switch, you're preventing the module from being imported (even though it's "installed" and the files are present).
What may be your best option, if you want to keep the "-NoProfile" switch active, is to have a line at the top of your script to import the module before continuing. If you're using Warren Frame's "PSSlack" module, the command you need is:
> Import-Module PSSlack
I hit the same issue.
What helped was... copying the folder into C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules.
Yup, it makes a difference.
I'm coming onto a project that uses PowerShell to script the build. The build makes use of the WebAdministration module to manage the local IIS instance. When I run the build script the following error is thrown when trying to import WebAdministration.
Error: 06/29/2016 17:28:35: At
C:\dev\src\nib-ravendb\build\ConfigureIis.ps1:10 char:1 +
Import-Module WebAdministration + ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
[<<==>>] Exception: The specified module 'WebAdministration' was not
loaded because no valid module file was fo und in any module
directory. ERROR: 1
How ever when I run Import-Module WebAdministration at the PowerShell command line the module is imported and I can use features from it. Subsequently running the build script still fails.
I have IIS 7.5 and PowerShell 4
Does anyone have an idea why this import would be failing in the script but not at the command line, and how to fix it?
For servers you need to install the role Management Tools under Web Server (IIS) to use the WebAdministration module. To see if you have the module available use Get-Module -ListAvailable.
For Windows 7 to 10 you will need to install the feature IIS Management Scripts and tools under Internet Information Services >> Web Management Tools.
You could try manually locating the WebAdministration .psd1 file and then import it. Use $env:psmodulepath to help locate where your modules are stored then run:
Import-Module -Name 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WebAdministration\WebAdministration.psd1'
If Server 2008 you could try the following but this may not work on 2012 and upwards:
Add-PSSnapin WebAdministration
Note You will need to run the script with administrator rights to be able to load the WebAdministration module with Import-Module or Add-PSSnapin.
Also check that you have PowerShell's execution Policy set to Unrestricted:
Set-ExecutionPolicy unrestricted
You might want to see this Question.
I had the same situation, i've fixed it installing the Windows Feature Web-Scripting-Tools on W2016 Server:
Add-WindowsFeature Web-Scripting-Tools
In the end there was a problem something, possibly chocolatey?, was truncating $env:PSModulePath to the first entry, this is why the script was working if I typed it in but not in the script.
I found it by logging $env:PSModulePath at different points in the scripts that I was running.
I worked around it by reordering the entries in $env:PSModulePath.
Have a look at #Richard's answer for some other good suggestions.
In my case (Windows 10) I was using Powershell 7 and this simply refused to install the WebAdministration module, despite it being present in Windows Features.
Using a previous version of PS: e.g. Developer PowerShell for VS worked.
introduction
I've written my first PowerShell script aimed for retrieving detailed information from a Windows Setup ISO file. Once the basic features achieved, I've started to convert the ps1 script into a psm1 module. I hoped the result would be the module just work like the script but I'm facing issue I'm not able to solve.
You can download my work here, script version and module (roughly translated to English from French).
I successfully installed the module in PSModulePath in:
[Environment]::GetFolderPath("mydocuments")\WindowsPowerShell\Modules
Command usage is very simple. You call it like that:
WinIsoInfo [[-Path] <String>] [<CommonParameters>]
Help is provided by module: man WinIsoInfo
Usage Example:
WinIsoInfo -Path "E:\Win 10\Installation\ISO\Windows 10 x64 fr.iso"
The ps1 script version is the exact same code as the psm1 module but there are commands examples at the end of the file that you can un-comment and edit before running the script.
Current Status
All the tests are and need to be run as admin, in console or PowerShell ISE.
The ps1 script works as expected but the psm1 module doesn't produce the same result.
At line 108 of the code, there is a Test-Path in a Switch statement:
{(Test-Path "$wimPath\sources\install.wim") -or (Test-Path "$wimPath\sources\install.esd")}
In the ps1 script, this Test-Path return True and user get the expected info.
But in the psm1, it seems to return False since Switch statement jump to the next test after this one. So at the end the user gets that the ISO doesn't contain windows setup. I can assure that the Test-Path should return True because I manually checked it while the function was paused by breakpoints.
Hint and lead
There are 2 cases where I manage to get the module work as expected. But only using in PowerShell ISE, NOT in console.
Using Automatic Variable $? in console pane while debugging module
Step to reproduce:
PowerShell ISE is not running.
Open PowerShell ISE as admin.
In console pane, run import-module Get-WinIsoInfo -Force -Global -Verbose or import-module -path X:\Path\To\Modules\Get-WinIsoInfo -Force -Global -Verbose
In console pane, run WinIsoInfo -Path "X:\path\to\AnyWindowsSetup.iso"
In my case, at this point, the command returns there is no Windows Setup in ISO file.
Now open the Get-WinIsoInfo.psm1 and put a breakpoints anywhere between line 90-108.
do step 4 again
While the script is paused at breakpoints, run $? in the console pane then press F10 then F5
And "voilà !" the module return the expected result and will keep working but only during PowerShell ISE session and inside PowerShell ISE. Command run in console still won't work. And the next time I run PowerShell ISE, the module won't find the setup image path again.
Previously run the ps1 script version in PowerShell ISE
Step to reproduce:
PowerShell ISE is not running.
Open PowerShell ISE as admin.
In console pane, run import-module Get-WinIsoInfo -Force -Global -Verbose or import-module -path X:\Path\To\Modules\Get-WinIsoInfo -Force -Global -Verbose
In console pane, run WinIsoInfo -Path "X:\path\to\AnyWindowsSetup.iso"
In my case, at this point, the command returns there is no Windows Setup in ISO file.
Now open the Get-WinIsoInfo.ps1 script, edit a valid command at the end of the code then press F5 to run it.
Note: Since the command in script has the same name as the module previously imported, at this point I don't know if the triggered function is the one from the ps1 script or the one from the module. Tell me if you know.
The script returns the expected result as Windows Setup info.
Close the ps1 file (it is no longer needed in PowerShell ISE for the next to work)
do step 4 again
And "voilà !" the module return the expected result and will keep working but only during PowerShell ISE session and inside PowerShell ISE. Command run in console still won't work. And the next time I run PowerShell ISE, the module won't find the setup image path again.
Conclusion
After the Hint and lead tests, I found out that they were some differences from modules imported in session before and after success. These key modules loaded by PowerShell ISE are Storage and Microsoft.WSMan.Management. I thought I found the solution and added this line to manifest:
RequiredModules = #("Storage";"Microsoft.PowerShell.Management";"Microsoft.PowerShell.Security";"Microsoft.PowerShell.Utility";"Microsoft.WSMan.Management")
I added all the modules that was present after the module works as expected, just to be sure.
I did the same for assemblies but 2 of them could not be imported: Microsoft.Management.Infrastructure.UserFilteredExceptionHandling and Microsoft.Management.Infrastructure.resources
Resulting in this new manifest line:
RequiredAssemblies = #("Microsoft.Management.Infrastructure.Native";"Microsoft.WSMan.Runtime";"System.Security")
Unfortunately, it seems it is not enough to solve the issue.
Maybe other things has to be imported or it's a wrong lead.
I really hope you could reproduce the bug or at least I hope the Hint and lead section will lead you to find the cause and a solution. I'm too novice to understand why this happens on my system.
My setup uses PowerShell v5.0 with Win 8.1 Pro.