This article is eagerly awaiting to be written (honestly)!

Some cmdlets can provide verbose data. This is disabled by default but can be enabled by using the -Verbose parameter. This can be useful if you want to log an action or troubleshoot your scripts.

To view an example of this we will look at the Set-Alias cmdlet:

PS C:\> Set-Alias Time Get-Date -Verbose
VERBOSE: Performing operation "Set Alias" on Target "Name: Time Value: Get-Date".
PS C:\>

As I said some cmdlets doesn’t provide verbose information so if we use the parameter with the Get-Date cmdlet it doesn’t provide any additional verbose data:

PS C:\> Get-Date -Verbose

Monday, July 28, 2008 7:48:33 AM
PS C:\>

Generally you will find that the Verbose parameter works on PowerShell cmdlets that make some kind of change to the system.

The OutBuffer parameter determines how many objects will be buffered before calling the next cmdlet in the pipeline.

Instead of typing out -OutBuffer you can use -ob for short.

I will add more information to this page when I’ve used OutBuffer more and can provide some examples.

Like many other aspects of PowerShell, -ErrorAction kind of explains itself when you think of it. Basically it instructs PowerShell what action to take when an error occurs. The actions you can set are Continue (which is default), Stop, SilentlyContinue and Inquire. Let’s take a look.

Continue

You can verify that Continue is the default action by looking at the $ErrorActionPreference variable. We’ll be using the Stop-Process Cmdlet to test this.

PS C:\> $ErrorActionPreference
Continue
PS C:\> Stop-Process 206,304
Stop-Process : Cannot find a process with the process identifier 206.
At line:1 char:13
+ Stop-Process <<<< 206,304
Stop-Process : Cannot find a process with the process identifier 304.
At line:1 char:13
+ Stop-Process <<<

Since we know continue is the default error action we don’t need to use “-ErrorAction Continue”.

Stop

The Stop error action instructs PowerShell to stop executing after the first error.

PS C:\> Stop-Process 206,304 -ErrorAction Stop
Stop-Process : Command execution stopped because the shell variable "ErrorActionPreference" is set to Stop: Cannot find
a process with the process identifier 206.
At line:1 char:13
+ Stop-Process <<<

Compared to when we used “Continue”, PowerShell will only try to stop the process with id 206 and never move on to 304 since it failed to stop the first one.

SilentlyContinue

As you might guess SilentlyContinue acts like Continue with the exception that we don’t see the errors. To save some typing we don’t need to write out ErrorAction, we can use EA for short.

PS C:\> Stop-Process 206,304 -EA SilentlyContinue
PS C:\>

Inquire

Inquire informs us that there has been an error and lets us decide what to do.

PS C:\> Stop-Process 206,304 -EA Inquire

Confirm
Cannot find a process with the process identifier 206.
[Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is "Y"): h
Stop-Process : Command execution stopped because the user selected the Halt option.
At line:1 char:13
+ Stop-Process <<<

What if you just deleted 5000 accounts from your active directory domain by accident, what if there had been an easy way to make sure you were doing the right thing before the deletion. Would you have wanted to use it? I know I would. Just imagine you were planning on deleting all accounts which had been disabled for six months but you forgot some important switch and most of your accounts were gone because of that stupid switch.

Ok, so this might be a bit far fetched but these things can happen and if you are not 100 percent sure of what you are doing, it’s great to be able to see what the results of your actions will be before you take them.

Let’s say we’ve been taking random notes and just want to kill all notepad processes without having to choose if we want to save every single file. Working with the Get-Process, Where-Object and Stop-Process cmdlets we decide to kill all the processes which has “note” in them.

PS C:\> Get-Process | Where-Object {$_.ProcessName -match "note"} | Stop-Process -Whatif
What if: Performing operation "Stop-Process" on Target "notepad (4284)".
What if: Performing operation "Stop-Process" on Target "notepad (4524)".
What if: Performing operation "Stop-Process" on Target "notepad (4848)".
What if: Performing operation "Stop-Process" on Target "notepad++ (4684)".
What if: Performing operation "Stop-Process" on Target "ONENOTE (5944)".
What if: Performing operation "Stop-Process" on Target "ONENOTEM (3876)".
PS C:\>

This would have wiped out every instance of notepad.exe along with my Onenote and notepad++ processes which was not what I wanted.

Lame example?

Yes, I guess you’re right that was quite a lame example. However I think it does illustrate how you can use the -whatif parameter. It can be very useful if you are working with important data and don’t want to make mistakes. Also it’s useful if your just playing around with PowerShell and learning what all the fuss is about.

It is said that we learn from our mistakes, and that to improve learning it’s best to write things down. How about storing our mistakes and errors in a variable? If that’s not killing two flies with one stone, at least it’s a useful feature of PowerShell. Let’s use it and see how it works, using the Stop-Service cmdlet we try to stop a service:

PS C:\> Stop-Service -name XAudioService -ErrorVariable myErrors
Stop-Service : Service 'XAudioService (XAudioService)' cannot be stopped due to the following error: Cannot open XAudio
Service service on computer '.'.
At line:1 char:13
+ Stop-Service <<<

As you can see the error is also written to screen. From now on we can reference the error in the $myErrors variable we created:

PS C:\> $myErrors
Stop-Service : Service 'XAudioService (XAudioService)' cannot be stopped due to the following error: Cannot open XAudio
Service service on computer '.'.
At line:1 char:13
+ Stop-Service <<<

You might want to know that even if you don’t specify the -ErrorVariable parameter all the errors will be storied in a special error called $error.

Saving the error variable like we have done above will ensure that you have the last error saved. One thing you can do is to add a plus sign before the variable when you want to append to the error variable. Here is an example:

PS C:\> Stop-Service -name XAudioService -ErrorVariable +myError
PS C:\> Stop-Service -name WinRM -ErrorVariable +myError
PS C:\> $myError.Count
2
PS C:\>

Imagine you are feeling handy and start out to rebuild your bathroom. Now imagine you’re standing knee deep in water in your basement. I bet you wished that somewhere in your head there was a tiny voice which had asked you, “do you really want to drill there”? This is the purpose of the PowerShell -Confirm parameter. If you’re running a cmdlet which changes the system state you can use -Confirm in order to get a question asking you if you really want to go ahead with the change.

Argh, my files, my precious files!

We’ve all heard horror stories of format c: and the like. At one point you might even have deleted files by mistake. With the Remove-Item cmdlet you can do just that.

PS C:\Temp> Remove-Item *
PS C:\Temp> <- That went smooth!

However wouldn’t this have been better:

PS C:\Temp> Remove-Item * -Confirm

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\junkfile1.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\junkfile2.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\junkfile3.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\Temp\single-copy-of-expense-report.xlsx".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): n

Lessons Learned

As the carpenters say; measure twice, cut once. Sometimes it’s better to step carefully unless you are really sure of what you are doing. The -Confirm parameter can be that little voice inside your head.

Building on the Perl motto; “There’s more than one way to do it”, PowerShell lovers will tell you that they can play too. Basically the -OutVariable parameter stores the output from a cmdlet to a variable and at the same time letting the cmdlet display all the output to the screen. For example looking at the Get-ChildItem cmdlet you can store the output in a variable by doing:

$myChildren = Get-ChildItem

Using the -OutVariable parameter you would instead type:

Get-ChildItem -OutVariable myChildren

This would also store the output in the myChildren variable (notice the lack of the $ sign), but unlike the first example the output would be printed to the screen.

This might sound a lot like the Tee-Object cmdlet. However you can also use OutVariable like this:

Get-ChildItem Directory1 -OutVariable myChildren
Get-ChildItem Directory2 -OutVariable +myChildren

This way the $myChildren variable would hold the contents of both Directory1 and Directory2. Another difference, if you’re in a hurry and want to juice out some performance, can be shown by the Measure-Command cmdlet.

Measure-Command {Get-ChildItem | Tee-Object -variable myTeeOutput}
TotalMilliseconds : 3,3151

Measure-Command {Get-ChildItem -OutVariable myOutVariableOutput}
TotalMilliseconds : 2,0668

Folks, we have a winner! But what will we do with all the extra free time?

If you just want to store the variable and not display the output you can use the Out-Null cmdlet:

Get-ChildItem -OutVariable myChildren | Out-Null

PowerShell uses for different settings called Execution Policy which governs how scripts will run on your computer and if they need to be digitally signed. Get-ExecutionPolicy is a Cmdlet which allows you to view which Execution Policy that is currently used by your computer.

SYNTAX

Get-ExecutionPolicy
-Verbose
-Debug
-ErrorAction
-ErrorVariable
-OutVariable

Examples

PS C:\> Get-ExecutionPolicy
Restricted

Probably the first thing you ever do whenever you learn a new language is to write your hello world program, however in PowerShell the most simple script will cause it to crash!

Instead of the friendly greeting PowerShell will spit back: “hello.ps1 cannot be loaded because the execution of scripts is disabled on this system.”

The error is fairly straight forward though, the Execution Policy governs whether you are able to run scripts or not. If you want to run scripts at all you have to change the execution policy.

Unrestricted

Unrestricted is the careless cowboy setting. If you set the Execution Policy to Unrestricted PowerShell will run any script regardless if it has a digital signature or not. As you might have guessed this is the worst setting in terms of security. Some things are fun to do in the short term, but you never know what kind of troubles you face down the road.

RemoteSigned

Using the RemoteSigned Execution Policy means that PowerShell will require that scripts downloaded from the Internet are signed by a trusted source. However you won’t have to signed scripts stored locally on your machine. This is a great setting if you just want to learn some scripting and take PowerShell for a test drive and don’t want to dive into the script signing business. Besides, you can always get your PKI environment up tomorrow.

AllSigned

The AllSigned policy requires every script you want to run to be signed by a trusted certificate, if you want to run scripts this is the setting which will let your sysadmin sleep soundly at night. In order to run your scripts you will have to get some script signing procedures in place.

Restricted

The Restricted option means that PowerShell will not run any script at all not even if it is digitally signed. You might be thinking that this would make PowerShell quite worthless as a scripting language, and you might be right. However PowerShell is also a shell and you can use it without ever writing a single script. Restricted is the default Execution Policy which is why your scripts won’t run when you start using PowerShell. In order to be able to run scripts you have to change the Execution Policy.

Changing the Execution Policy

You can change the Execution Policy with the Set-ExecutionPolicy cmdlet, to view your current Execution Policy you can use the Get-ExecutionPolicy cmdlet.