What does PowerShell’s [CmdletBinding()] Do?

It’s not unusual to see folks write PowerShell scripts and functions whose first line is [CmdletBinding()]. What’s it do?

It’s generally a big part of advanced functions, or what some folks call “script cmdlets.” Basically, it turns on cmdlet-style parameter binding capabilities, either for a script or for a function. You really get four magical capabilities with it:

  • The ability to add [Parameter()] decorators to parameters – see “about_functions_advanced_parameters” in PowerShell for more detail. Technically, these can be used without adding [CmdletBinding()], but you almost always see them together.
  • The ability to use Write-Verbose and Write-Debug in your script or function, and have their output controlled by -Verbose and -Debug parameters of that script or function. You don’t need to declare those parameters – [CmdletBinding()] adds them.
  • Your script or function picks up the other common parameters, too, like -EV and -EA (see “about_common_parameters”)
  • The ability to have -whatif and -confirm added to your script or function, by specifying something like [CmdletBinding(SupportsShouldProcess=$True,ConfirmImpact=Medium)]. You still have to implement support for these switches by using $pscmdlet.ShouldProcess() in your script.

Unblock a file with PowerShell?

If you are using PowerShell v3, you can use the Unblock-File cmdlet.

The “blocking” part is simply an alternate data stream of the file, named “Zone.Identifier”. You can display it in CMD by using input redirection (no other way to get to a stream in CMD, though):

H:\Downloads> more < test.exe:Zone.Identifier

You can find them using dir /r on Windows Vista and later:

2009-10-24  12:18        54.538.056 test.exe
                                 24 test.exe:Zone.Identifier:$DATA

Also in CMD you can easily get rid of that by overwriting it (using output redirection, this time):


which isn’t quite the same as removing the ADS completely, but works in that Explorer doesn’t complain anymore.

There doesn’t seem to be native support for handling ADS from within PowerShell (as mentioned on The PowerShell Guy’s blog here. That article also has some information how to get that functionality in PowerShell). You could, however, simply call cmd:

cmd /c "echo.>test.exe:Zone.Identifier"

That works from PowerShell as well.

Another option would be Mark Russinovich’s streams utility which allows you to inspect a file’s ADS and also to delete them. So

streams -d myDownloadedFile.exe

does work as well.

Variable scoping in PowerShell

ou can use scope modifiers or the *-Variable cmdlets.

The scope modifiers are:

    • global used to access/modify at the outermost scope (eg. the interactive shell)
    • script used on access/modify at the scope of the running script (.ps1 file). If not running a script then operates as global.


(For the -Scope parameter of the *-Variable cmdlets see the help.)

Eg. in your second example, to directly modify the global $array:

& {
  $global:array +="s"
  Write-Host $array

For more details see the help topic about_scopes.

Log4net tutorial – Great library for logging

log4net tutorial– Great library for logging

A lot of applications use logging as a way to store information about performed operations. Such data is very useful when you have to diagnose an issue. Logging could be done on many ways, but sometimes it’s just easier to use an existing solution. I’d like to introduce one of many libraries for logging, but quite powerful – log4net.

Get log4net

Let’s create a console application – log4netTutorial. Next you have to reference log4net library. The easiest way is to install NuGet package:

    • Right click your project
    • Click Manage NuGet Packages…
    • Click Online on the left hand panel
    • Type log4net in search box on the right side
    • Select log4net package and click Install

Continue reading “Log4net tutorial – Great library for logging”

How does the RemoteSigned execution policy work?


You might have wondered how the “RemoteSigned” execution policy protects us from running unsigned PowerShell scripts downloaded from the internet. We use the URL Security Zones API related to “Attachment Execution Service” (AES) introduced in Windows XP SP2 and Windows Server 2003 SP1. Internet Explorer and Outlook Express are among the applications that participate in the AES system, while FireFox, Microsoft Office Outlook and Live Messenger do not follow AES.

Continue reading “How does the RemoteSigned execution policy work?”

The object-orientedness of PowerShell and what you see may not be what you get

PS ewu\My Documents\GitHub\PowerShell> get-aduser ewu -Properties LastLogonDate | Select LastLogonDate

1/1/2016 6:22:01 PM

PS ewu\My Documents\GitHub\PowerShell> get-aduser ewu -Properties LastLogonDate | Select LastLogonDate | gm

TypeName: Selected.Microsoft.ActiveDirectory.Management.ADUser


PS ewu\My Documents\GitHub\PowerShell> (get-aduser ewu -Properties LastLogonDate | Select LastLogonDate).LastLogonDate

Friday, January 01, 2016 6:22:01 PM

PS ewu\My Documents\GitHub\PowerShell> (get-aduser ewu -Properties LastLogonDate | Select LastLogonDate).LastLogonDate | gm

TypeName: System.DateTime


PS ewu> (get-aduser ewu -Properties LastLogonDate | Select LastLogonDate).LastLogonDate

Friday, January 01, 2016 6:22:01 PM

PS ewu> ((get-aduser ewu -Properties LastLogonDate | Select LastLogonDate).LastLogonDate | Out-String) -like “*Jan*2016*”

PS ewu> (get-aduser ewu -Properties LastLogonDate | Select LastLogonDate | out-string)

1/1/2016 6:22:01 PM

PS ewu> (get-aduser ewu -Properties LastLogonDate | Select LastLogonDate | out-string) -like “*1*2016”

&& and || operators

The right side of && will only be evaluated if the exit status of the left side is zero. || is the opposite: it will evaluate the right side only if the left side exit status is nonzero. You can consider [ … ] to be a program with a return value. If the test inside evaluates to true, it returns zero; it returns nonzero otherwise.

$ false && echo howdy!

$ true && echo howdy!
$ true || echo howdy!

$ false || echo howdy!

SSH Tunnel – Local and Remote Port Forwarding Explained With Examples


There are two ways to create an SSH tunnel, local and remote port forwarding (there’s also dynamic forwarding, but we won’t cover that here). The best way to understand these is by an example, let’s start with local port forwarding.

Imagine you’re on a private network which doesn’t allow connections to a specific server. Let’s say you’re at work and imgur.com is being blocked. To get around this we can create a tunnel through a server which isn’t on our network and thus can access Imgur.

$ ssh -L 9000:imgur.com:80 [email protected]

The key here is -L which says we’re doing local port forwarding. Then it says we’re forwarding our local port 9000 to imgur.com:80, which is the default port for HTTP. Now open your browser and go to http://localhost:9000.The awesome thing about SSH tunnels is that they are encrypted. Nobody is going to see what sites you’re visiting, they’ll only see an SSH connection to your server.

Connecting to a database behind a firewall

Another good example is if you need to access a port on your server which can only be accessed from localhost and not remotely.An example here is when you need to connect to a database console, which only allows local connection for security reasons. Let’s say you’re running PostgreSQL on your server, which by default listens on the port 5432.

$ ssh -L 9000:localhost:5432 [email protected]

The part that changed here is the localhost:5432, which says to forward connections from your local port 9000 to localhost:5432 on your server. Now we can simply connect to our database.

$ psql -h localhost -p 9000

Now let’s stop here for a little bit an explain what is actually going on. In the first example the 9000:imgur.com:80 is actually saying forward my local port 9000 to imgur.com at port 80. You can imagine SSH on your server actually making a connection (a tunnel) between those two ports, one on your local machine, and one on the target destination.If we however say something like 9000:localhost:5432, it means localhost from the server’s perspective, not localhost on your machine. This means forward my local port 9000 to port 5432 on the server, because when you’re on the server, localhost means the server itself.

This might be a bit confusing, but it is important to understand what the syntax actually means here.

Remote port forwarding

Now comes the second part of this tutorial, which is remote port forwarding. This is again best to explain with an example.Say that you’re developing a Rails application on your local machine, and you’d like to show it to a friend. Unfortunately your ISP didn’t provide you with a public IP address, so it’s not possible to connect to your machine directly via the internet.

Sometimes this can be solved by configuring NAT (Network Address Translation) on your router, but this doesn’t always work, and it requires you to change the configuration on your router, which isn’t always desirable. This solution also doesn’t work when you don’t have admin access on your network.

To fix this problem you need to have another computer, which is publicly accessible and have SSH access to it. It can be any server on the internet, as long as you can connect to it. We’ll tell SSH to make a tunnel that opens up a new port on the server, and connects it to a local port on your machine.

$ ssh -R 9000:localhost:3000 [email protected]

The syntax here is very similar to local port forwarding, with a single change of -L for -R. But as with local port forwarding, the syntax remains the same.First you need to specify the port on which the remote server will listen, which in this case is 9000, and next follows localhost for your local machine, and the local port, which in this case is 3000.

There is one more thing you need to do to enable this. SSH doesn’t by default allow remote hosts to forwarded ports. To enable this open /etc/ssh/sshd_config and add the following line somewhere in that config file.

GatewayPorts yes

Make sure you add it only once!

$ sudo vim /etc/ssh/sshd_config

And restart SSH

$ sudo service ssh restart

After this you should be able to connect to the server remotely, even from your local machine. The way this would work is that you would first create an SSH tunnel that forwards traffic from the server on port 9000 to your local machine on port 3000. This means that if you connect to the server on port 9000 from your local machine, you’ll actually make a request to your machine through the SSH tunnel.

A few closing tips

You might have noticed that every time we create a tunnel you also SSH into the server and get a shell. This isn’t usually necessary, as you’re just trying to create a tunnel. To avoid this we can run SSH with the -nNT flags, such as the following, which will cause SSH to not allocate a tty and only do the port forwarding.

$ ssh -nNT -L 9000:imgur.com:80 [email protected]

SSH has a huge number of features, so I’d recommend you to checkout the manual page at man ssh, which contains even more tips.There’s also an amazing talk called The Black Magic of SSH / SSH Can Do That?, which I really recommend you to watch.

Linux Articles