Suppressing VERBOSE for Import-Module - powershell

I'm importing Carbon into my PowerShell script; however when running my script with -Verbose, Carbon also outputs a lot of VERBOSE statements.
Is it possible to Import-Module silently such that I can ignore the verbose statements in the imported module and leave just my own?

Try Import-Module Carbon -Verbose:$false

I could not get the solutions above to work with all modules (I'm using Powershell 4.0). This is the solution I ended up using and so far it has worked with every module I've used:
At the top of my script file I have this, to make the -Verbose work for the script (the script has no parameters):
[CmdletBinding()]
Param()
Then when I'm ready to import the modules, I do this:
$SaveVerbosePreference = $global:VerbosePreference;
$global:VerbosePreference = 'SilentlyContinue';
Import-module "Whatever";
$global:VerbosePreference = $SaveVerbosePreference;
Then I just call the script like so:
PowerShell -file something.ps1 -Verbose

Import-Module Carbon -Verbose:$false | Out-Null

I think a better solution than the one which is marked here is to redirect the verbose output to a different stream. This way you can print the output if you need it and it doesn't get swollen for ever:
Import-Module Carbon 4>&5
This redirects the verbose stream (4) to the debug stream (5). When you run your script with the Verbose switch, it will not output the verbose lines from Import-Module, but you can bring it back by running your script with the -Debug switch.

As Carbon seems to be a script module, can you try to set the $script:VerbosePreference (or just $VerbosePreference) to 'SilentlyContinue' inside the module itself carbon.psm1. The module scope should do the trick.

First contribution, I hope this helps.
ipmo $dir\$i 3>$null
ipmo: Short-hand/alias for Import-Module
3>$null: Redirect warnings messages to null
Edit:
I wanted to share a table I found at work while I was looking for the best way to help explain this... But I cant find it now. However, the quick an dirty is you may have already noticed that ipmo doesn't act like the rest of those PWshell cmdlet. It has a total of 4 streams in the bg.
I don't remember 1 and 2. 3 is warning. 4 though, 4 is not necessarily error, but it is error at the same time? I don't remember the exact wording. It is something that bypasses errors.
If I do find that award winning table again I'll be sure to share the blessing.

Related

How to prevent Powershell from printing warnings on the output?

I am executing a PS script to display few things from Azure. But, for some cmdlets the warnings gets written to the output.
like this:
WARNING: AzureRM.Profile already loaded. Az and AzureRM modules cannot be imported in the same session or used in the same script or runbook. If you are running PowerShell i n an environment you control you can use the 'Uninstall-AzureRm' cmdlet to remove all AzureRm modules from your machine. If you are running in Azure Automation, take care th at none of your runbooks import both Az and AzureRM modules. More information can be found here: https://aka.ms/azps-migration-guide.
I have used the -ErrorAction SilentlyContinue which will prevent the errors from printing. But is there a way to avoid warnings in the output while executing the command.
P.S: I am well aware of how to get rid of the above warning. Just curious if there is any way we can keep the warnings from displaying.
You're trying to use -ErrorAction on a Warning, which is not an Error.
To silence Warnings, you need to use -WarningAction SilentlyContinue

Not able to get New-F5Item cmdlet

I am creating a pool in F5.
i came across the below link which gives a function of creating a Pool.
(https://www.powershellgallery.com/packages/f5-ltm/1.4.154/Content/Public%5CNew-Pool.ps1)
All the things are fine. i have installed F5-LTM module for powershell also.
Install-Module -Name F5-LTM -RequiredVersion 1.4.280
I am not able to see the "New-F5Item" cmdlts.
Can you please let me know about this cmdlet.
Thank you
If you look at the file list in PSGallery, you'll notice that the package contains the script file Private\New-F5Item.ps1, indicating that New-F5Item is probably not exported by the module.
When a command is not exported, it can only be discovered/called from other functions in the same module - which is why you don't see it when doing Get-Command or similar.

How do I force powershell to reload a custom module?

I have created a module 'ActiveDirectory.psm1' which contains a class in powershellv5. I am importing that module in another file called 'test.ps1' and then calling a method from the class.
test.ps1 contains the following:
using module '\\ser01\Shared\Scripts\Windows Powershell\modules\ActiveDirectory\ActiveDirectory.psm1'
Set-StrictMode -version Latest;
$AD = [ActiveDirectory]::New('CS');
$AD.SyncGroupMembership($True);
It all works as expected BUT when I make a change to ActiveDirectory.psm1 & save the changes they aren't reflected immediately. i.e. if ActiveDirectory.psm1 contains:
write-verbose 'do something';
If I change that to
write-verbose 'now the script does something else';
the output remains 'do something'
I'm guessing it has stored the module in memory and doesn't reload it therefore missing the changes I have made. What command do I need to run to load the most recent saved version of the module?
As suggested by wOxxOm, you can try pass the -Force flag:
Import-Module ... -Force
Or if that does not work try to explicitly remove it and then reimport with:
Remove-Module
From what I've gathered. Import-Module does not import classes. You have to use the "using module " and it has to be in the first line of your script. On top of that problem, the classes appear to be "cached" in some esoteric way that precludes any uninstall-module or remove-module options. I've found I basically need to restart my powershell terminal to clear it.
If classes are not involved use import-module OR install-module. In both cases you can do a get-modules -all or get-installedmodule and then remove-module or uninstall-module. You want to make sure you look for all versions and pipe that to remove/uninstall to ensure you wipe everything out.
For anyone else coming across this issue, see https://github.com/PowerShell/PowerShell/issues/2505
It seems that there is a known long-standing bug regarding importing of modules that are anything above rudimentary level in complexity (for example, I have a module with a single class and class method that fails to update).

wusa silent install error

I am trying to automate updating Powershell on Windows 7 using Windows6.1-KB2506143-x64.msu, and having a heck of a time. The following code works fine in a standalone ps1 file. And it works in my main ps1 file. But when run from a module it fails with exit code -2145124341. This is in PS v2, where negative exit codes are handled wrong, so that number is perhaps useless, and FWIW I have a good 40 other installers of various types that work from this module. However, this is my first attempt at automating msu files, so maybe there is a known interaction here that I haven't discovered yet? There's thousands of lines of code between the root ps1 file where this works and the module where it doesn't, so tracking down what is triggering the error is going to be a beast without some sort of trail to follow at the very least. So, anyone have an idea where I should start?
$filePath = 'wusa.exe'
$argumentList = '"\\PX_SERVER\Rollouts\Microsoft\Windows6.1-KB2506143-x64.msu" /quiet /norestart'
$exitCode = (Start-Process -filePath:$filePath -argumentList:$argumentList -wait -errorAction:stop -passThru).exitCode
Also, running wusa.exe leaves some detritus in the script folder, but only when it is run from the module. Is this an issue with the msu file, or just a bug in wusa? Or does it point at what is causing the issue perhaps?
I had hoped to get this update to work to enable some new features, but between not being able to automate and garbage being left behind, I am very close to abandoning that path and juts continuing to target v2. But hopefully someone can point me in the right direction as that is not my preferred solution at all.
a few toughts on first reading :
The ArgumentList parameter for Start-process needs an ARRAY to work well :
$argumentList = #( "\\PX_SERVER\Rollouts\Microsoft\Windows6.1-KB2506143-x64.msu", "/quiet", "/norestart" )
wusa.exe takes a log parameter : /log:c:\fso\install.log can you had it to your script for this particular package to check what happens ?
a powershell script trying to update powershell ... I'm not quite sure this is meant to work ... it's the only case in wich i'll backup on another scrpting language (people, please correct me if i'm wrong ... )
Please let me know the result of the wusa.exe /log command, thanks

Is it possible to/how do you stop powershell using certain cmdlets?

Powershell is clearly a lot better than cmd but it hides basic functionality. I normally use it to figure out how to use commands that I want in scripts but it breaks a large number of basic things and I end up using both side by side if I hit a sticky spot.
Today this was removing a directory - rd or rmdir - both of which are broken in powershell in favour of one it's undocumented (from the commandline) cmdlets Remove-Item. I seem to run into it all the time though - sc (for mucking around with services); where for finding what program is being called when you type a command etc etc.
Hilariously I actually got the problem with sc and then googled to find out the command where only to discover that didnt work in powershell either! That was a confusing day
In some cases once you know this is what's going on you can type the full exe name (for instance 'where.exe' will work whereas 'where' on its own wont).
This isn't the case with rmdir however. Although interestingly typing 'where rmdir' in cmd doesnt work.
So... my question is this - Is there a way of turning off (preferably all) cmdlets in powershell and just getting the normal stuff instead?
There is no need to turn off cmdlets in powershell as that would destroy the very reason for having it.
Most of the "normal" stuff is there anyway, which you can find by using the get-alias command.
C:\> get-alias
CommandType Name
----------- ----
Alias % -> ForEach-Object
Alias ? -> Where-Object
Alias ?? -> Invoke-NullCoalescing
Alias ac -> Add-Content
Alias asnp -> Add-PSSnapin
Alias cat -> Get-Content
Alias cd -> Set-Location
Alias chdir -> Set-Location
.....
..... AND A WHOLE LOT MORE!
If you are missing a command that you really, really want to have, then you can easily add a new alias:
Set-Alias python2 "C:\Python27\python.exe"
In order to avoid having to do this every single time, you can simply add this into your startup profile. Just type in $PROFILE into the command prompt and it will show you the file path. If it doesn't exist, simply create it, and any powershell commands you add to the top will be automatically invoked when you start a new session.
And last thing. All of the commands are documented, and you can get to them easily using just two.
Just type this into your command prompt and you will be on your way to Powershell enlightenment!
get-help get-command
get-command -noun Item
get-command -verb get
I just realised the answer to my question was buried in the comments to the other answer:
To remove a cmdlet in powershell you run
Remove-Item alias:something.
I can confirm you can do this by using the profile mentioned in Josh's post, however there are a couple more steps:
By default you cant run scripts in powershell. You have to change this using set-ExecutionPolicy.
I changed this by using an admin powershell and typing
set-executionpolicy bypass
This will let you run any script you like
Then in my profile script I have lines like:
Remove-Item -force alias:sc
You wont see errors from this script when it runs and it wont do anything unless you have force.