I have a really wierd problem when I write a PowerShell script using Visual Studio Code.
After I finish executing my script I make some changes to the script, but when I start the script again, these changes do not get executed.
I thought maybe I have to little RAM, but I use a Lenovo T570 with 8GB.
Also sometimes during debugging my script I get a error message which says: PowerShell terminated unexpectedly.
does anyone have any idea what the problem might be?I use VS Code 1.30 and the latest PowerShell Add-In
If the Powershell script is using a module that you have changed, these changes will not take effect once that module was already loaded into memory.
You can try and force the updated module to reload by adding
Remove-Module xxx
before importing it with
Import-Module xxx
You can also try using the -Force parameter on the Import-Module cmdlet:
Import-Module xxx -Force
Related
I have a machine i would like to install a module on, specifically SwisPowerShell for working with SolarWinds. Internet is disabled on it so i cant use install-module, so i manually downloaded the .nupkg from another machine and went through the steps of unpacking the files into the correct folders. https://learn.microsoft.com/en-us/powershell/scripting/gallery/how-to/working-with-packages/manual-download?view=powershell-7.2. all the .dll files and the windows powershell datafile i have tried in both directories "C:\Program Files\WindowsPowerShell\Modules\SwisPowerShell\3.1.0.343" and "C:\Users\username\Documents\WindowsPowerShell\Modules\SwisPowerShell\3.1.0.343". Importing the module with "import-module -name SwisPowerShell -Global -force -Verbose" shows that everything loads correctly, but then running "get-module SwisPowerShell -Verbose" returns nothing. even loading each dll individually with "add-type -path "C:...\somefile.dll" shows nothing. running "get-module -ListAvailable" shows the module in both (or either) directories as they should be. using "get-help cmdletname" and "get-command cmdletname" shows the correct cmdlet definitions. trying to run any of the cmdlets returns "The term 'connect-swis' is not recognized as the name of a cmdlet, function... yada yadda" for all of the cmdlets. its like powershell sees the files but refuses to use them. Am i missing a step that tells powershell that this is a valid module to use? could it be blocked somehow? what extra steps does install-module do that a manual install does not that i could try?
Try running process monitor while installing on another machine. You might find out it's doing some registry changes too.
I'm working with DNS resource records in Powershell 5 using code that I inherited from the guy who was trying to do this before me. The cmdlet I am trying to use is Add-DnsServerResourceRecordA.
Part of his code has import-module certain folder\PowerShell\Modules\DnsServer. The weird thing is, it seems like as I was trying bits and pieces of the code earlier, I was able to use the add-DNSblah cmdlet. Now, after It ried running the whole script including the import-module, Powershell is saying that the cmdlet does not exist natively, and when I import the module and run it it is giving me Add-DnsServerResourceRecordA: Invalid Class.
It is my understanding that Add-DnsServerResourceRecordA should be included in my normal Powershell 5.0. Could that Import-Module have permanently damaged PS somehow? Why else would the cmdlet not show up, even in a Get-Command "dns"?
I'm pretty sure you will need the Remote Server Administration Tools (RSAT) installed to have these cmdlets available on a non-server Windows OS.
You can download them from this page: https://www.microsoft.com/en-gb/download/details.aspx?id=45520.
Not really sure why the Import-Module does not fail if the DNSServer module is not present on the system.
If RSAT are already installed, you can try to reinstall them.
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.
I have the following code as the beginning of a longer script:
$ScriptPath = Split-Path $MyInvocation.MyCommand.Path
& $ScriptPath\build_functions.ps1
& $ScriptPath\build_builddefs.ps1
The idea is to get the path of the script being run and use that path to call some supporting scripts. However when I went to test this out in isolation to make sure it could work (by highlighting that block and running just that code), I got the following error:
Split-Path: Cannot bind argument to parameter 'Path' because it is null.
Interestingly enough, when I run the entire script it seems to run these files separately. Is there something I'm missing about how the ISE handles running a selection rather than the full script? Does it not establish a file system context when you run a selection?
$MyInvocation is an automatic variable populated at script run time, then if you execute $MyInvocation.MyCommand.Path in a powershell console or ISE isn't populated;
that's why in your test the $ScriptPath has no value ($null)
I don't if what happened to me was why some where seeking null in $MyInvocation.MyCommand.Path, but I will explain how I found the solution.
I had scripts that were working in production, yet when I loaded the .ps1 file up and tried to get $MyInvocation.MyCommand.Path it was null. My version of Powershell was 4.0, but 1.0 for the ISE (%windir%\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe).
But it didn't occur to me at first why they should work, yet when I manually inspected $MyInvocation.MyCommand.Path or $MyInvocation in PowerShell why it was null, and why I was getting a null error for Split-Path -parent $MyInvocation.MyCommand.Path.
So I thought I needed to upgrade the powershell to 5.1 on my Windows 2012 R2 Server like on my desktop NUC PC.
The real problem was that I found that if I set a break point in my .ps1 file and ran it to the spot where I was doing:
$ScriptDir = Split-Path -parent $MyInvocation.MyCommand.Path
That it worked. Of course it worked, I had been using it for a while. Why didn't I see it before?
What went wrong? I was trying to manually run the PowerShell in pieces using the run step command, when I had never run the script before since PowerShell was open!
I have to say this is probably a No Duh moment.
But we had recently had a server crash and had it restored (VSphere Clustered) and reseeded, so I thought maybe I have an older version of PowerShell.
PowerShell allows you to have multiple files/windows open inside it, yet the variables are shared between them. Apparently until you actually try to run the script (not step by step run), it has no script file executing and can't get you the path.
I hope this post saves someone from wasting a bunch of time like I did!
i think you need write just:
& .\MySuperDuperScript.ps
I have a problem I cannot solve without help )
I have SCOM in first PC, and I have SCOM agent in second. When my class discoveries in agent PC, it must run PowerShell script. This script contains command:
Import-Module FailoverClusters
but this command fails with exception:
The following error occurred while loading the extended type data file:
Microsoft.PowerShell, C:\Windows\system32\WindowsPowerShell\v1.0\Modules\FailoverClusters\FailoverClusters.Types.ps1xml : File skipped because it was already present from "Microsoft.PowerShell".
I dont know what to do.
As this blog post points out, you can ignore extended type data errors when loading modules. It's telling you that the type is already loaded and it can't load it a second time.
WORKAROUND:
I found that with SCOM 2007 R2 (haven't tested this on SCOM 2012), powershell fails to import FailoverClusters module. I tried the suggestion to skip the error. Skipping works the very first time the agent executes the script. After that, subsequent executions of the script fail to have the Get-Cluster cmdlet available. Whenever you restart the agent, it skips the error and the cmdlet is available, but again subsequent executions fail to load the cmdlet.
Elevated permissions and unrestricted script execution didn't help the issue.
Restarting the agent regularly is such a sledge hammer. I did not entertain it.
However I did find that if I used a light-weight script that spawns a new powershell instance and executes my main code (file saved on disk or generate the script on disk on the fly), the fresh powershell instance loaded the module successfully every time and the cmdlet was always available.
I know there are concerns that spawning one instance from another (like vbscript spawing powershell) has perf issues. But in my case, I was able to have the agent call my powershell wrapper, generate a 500 line script on the fly (using streamwriter for perf), and then spawn it in a fresh powershell form the wrapper. It all executed in about 6 seconds, which included querying Get-ClusterResources.
I'm guessing this is a bug in the SCOM agent...
Powershell Script (GPO_Discovery.ps1) called WriteErrorLine method to output the following data:
Import-Module : The following error occurred while loading the extended type data file:
Microsoft.PowerShell, C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ActiveDirectory\ActiveDirectory.Types.ps1xml : File skipped because it was already present from "Microsoft.PowerShell".
As it can be seen, I have the same problem on trying to run :
Import-Module ActiveDirectory
Import-Module GroupPolicy
So I tried:
Import-Module -Name ActiveDirectory -OutVariable $outAD -ErrorAction SilentlyContinue
Import-Module -Name GroupPolicy -OutVariable $outGP -ErrorAction SilentlyContinue
Neither of these have helped. I am about to attempt to remove the Import CMD-Let completely and try again. I will post if that works for me.