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.
Related
If I open a new Powershell 7 session and run get-command Get-Website
the response I get is
Get-Command: The term 'Get-Website' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
If I then run import-Module WebAdministration and again run get-command Get-Website, this time I get the expectefd output of
CommandType Name Version Source
----------- ---- ------- ------
Function Get-Website 1.0 WebAdministration
If I close the Powershell 7 session, open a new one and run get-command Get-Website, the new session does not recognise the command.
If I run a session of Windows Powershell, I do not have to import the module, the command is already there.
Anyone able to explain what is going on?
Thanks
You are not the only person having this problem. Unfortunately, I can't speak to whether any of the solutions there work, as neither the asker or anyone else has confirmed them.
Note: I had originally suspected this might be a problem with automatic importing through the WindowsCompatibility module, but it appears that it does not interfere with auto-importing of modules. In addition, as of PowerShell 7 the WindowsCompatibility module features are baked into PowerShell itself.
For whatever reason, WebAdministration may not be able to be automatically imported in PowerShell Core. There are a few reasons for this but they are mostly on the module side, and you can't change the behavior without modifying the module.
You can try setting $PSModuleAutoLoadingPreference = 'All' in your current PowerShell session, but generally that doesn't need to be changed from the default value of ModuleQualified. More information on $PSModuleAutoLoadingPreference can be found here.
If that doesn't work, you'll have to manually import the module in every session.
Fortunately, manually importing modules isn't required for the vast majority of them. For the ones which can't be automatically imported, you must use Import-Module MODULENAME in each new session. You can simplify this by adding the Import-Module cmdlet to one of the following profile locations:
$profile.CurrentUserCurrentHost
$profile.CurrentUserAllHosts
$profile.AllUsersCurrentHost
$profile.AllUsersAllHosts
For scripts, Import-Module should generally be done inside the script to prevent needing profiles in scenarios where profile loading is desired to be disabled such as when PowerShell is invoked in the following way: powershell.exe -NoProfile ....
In your case, it would like like so:
Import-Module WebAdministration
Here is some additional information about the $profile variable.
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 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
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.
There is a Jenkins node running at Windows Server 2012 R2 host.
There is a build job with "Windows PowerShell" step and command
Import-Module -Name:'WebAdministration'
Job is failing with error
Import-Module : The specified module 'WebAdministration' was not loaded because no valid module file was found in any module directory.
If I'm logging in as user which is running that node then manual execution of
Import-Module -Name:'WebAdministration' is fine.
The same job after manual module import will work for some time and then it starts failing again.
Could anyone give a tip what could be wrong?
The error indicates the running instance could not find the module file. I'd recommend try Import-Module with absolute path to the slave
e.g, you module is placed on C:\PSModule\Webadmin folder on the slave
Import-Module "C:\PSModule\Webadmin"
This should point to the desired module file and resolve the problem.
Alternatively, you can give add-pssnapin WebAdministration a shot, might land different result.