CmdLets (pronounced “Command Lets”) are the building blocks of Powershell scripts.  You can think of them as being like keywords in a programming language. In reality however CmdLets are mini-programs. As you may recall, Windows Powershell is basically built on top of the .Net Framework and a CmdLet simply packages together multiple .Net Framework commands and methods into an easy to use package so that if you’re not used to programming the .Net Framework, are a CLI script writer, you don’t actually have to learn the .Net Framework and it’s thousands of classes and methods in order to use PowerShell.

Windows Powershell 2 comes packaged with well over 100 CmdLets for you to choose from ranging from simply writing out text to the PowerShell window to advanced functionality like Transactions.  To get a complete list of CmdLets that are available in PowerShell 2 can simply enter :-

get-commands

into your Powershell console. This will list not only the CmdLets but their aliases as well. 

 

To make it a bit easier to read you can issue the following command :-

get-command | out-gridview

The out-gridview CmdLet takes the output from any command and displays it in a searchable window :-

As you can see there are a mixture of functions, aliases and CmdLets. What is an Alias?  Microsoft added Aliases to most CmdLets to help CLI script writers easily transfer over to Powershell. For example, to get a directory listing of the current directory you would use the following CmdLet :-

get-childitem

As you can see, this basically just gives you a listing of all the files and folder in the current directory. CLI programmers however are used to the old DIR command :-

As you can see the output is exactly the same. That is because DIR is just an Alias for get-childitem. There is also another Alias for this command for unix programmers – LS. You can have multiple Aliases for a single CmdLet, depending upon your preference and what you are used to.

So you have all these commands at your disposal but what do they all do? Well it’s easy to get help on any CmdLet in PowerShell. You simply use the Get-Help CmdLet :-

As you can see, if you just enter Get-Help by itself then it will give you help about the Get-Help CmdLet itself. From the output however you can see that you can enter the name of a CmdLet as a parameter and it will show you the help for that particular CmdLet, e.g. get-help write-host :-

You can also get information about a specific CmdLet from the graphical help file (basically a CHM file). From within your PowerShell IDE (or ISE as it’s called in PowerShell), simply press the “F1” key or use the Help menu item :-

The built in Powershell help file is slightly different from the screenshot above as this is the PowerShell Plus help file. PowerShell Plus is a fully interactive PowerShell programming environment from Idera that I will be talking about more in a later posting but for those curious at the moment you can get details at http://www.powershell.com

Also in a later post I will show you how you can make your own CmdLets, after all, they are really just .Net Framework programs.

In the last article I showed you where to download Windows Powershell 2 and went through the installation steps along with some initial configuration options.

In this article I’ll complete the initial configuration options that you may want to do (note these are optional).

Windows Powershell, just like the CLI that it essentially replaces, looks in certain folders on your drive for commands. It is a good idea to create your own directory on your system to store your own Powershell CmdLets and scripts however if you do, how do you run these scripts if it’s not in the default paths?

Before getting ahead of ourselves, what are the default paths?  You can easily find this information out by opening Windows Powershell and inserting the following command :-

$env:Path

This will return a semi-colon delimited list of directories that Windows Powershell automatically searches through for the command that you are running.

By default, as you can see above, these are :-

C:\Program Files\Common Files\Microsoft Shared\Windows Live
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\
C:\Program Files\Microsoft SQL Server\100\DTS\Binn\
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\
C:\Program Files\Common Files\Microsoft Shared\Windows Live

Your default paths may vary from mine as I have various development tools installed that adjust the default path behaviors. As you can see, by default, the folder that you’ve just created to store your CmdLets and Powershell scripts will not be listed. This means that Powershell will not look in your folder for your scripts by default and therefore you cannot run them from anywhere on your system.  To include your Scripts folder so that it gets searched by default you need to adjust your system path environment variable. 

In Windows Vista or Windows 7 you need to open your System control panel applet. Go to Start menu, Control Panel then select System :-

From the System Control Panel applet, select the link advanced system settings  near the top left :-

At the bottom of this window you will see a button marked “Environment Variables”. This is the one you want. Click on it to bring up your system variable window. Note, if you do not know what these settings are then please don’t play about with them as you can end up rendering your computer inoperable.

The one that we are looking for is in the second list under System variables (although you could add it to your local variable path for if you wish however that would then only include that path for that particular user). Select Path then hit the edit button :-

To add your own folder, in the “variable value” field, scroll to the end without altering anything that is in there, type in a semi-colon “;” and then type in the full path to your folder. As you can see from the screenshot above, I’ve added ;C:\PScripts to the end as that is where I intend to store my Powershell scripts and CmdLets.  Next “OK” your way out of the dialogs, then you need to reboot your computer as these settings are only loaded on startup. And that’s it, now whatever Powershell scripts and CmdLets you place in this folder can automatically by run from whichever directory your actually pointing to at the Powershell prompt.

After rebooting your computer, if you now re-run the $env:path command in Powershell you should see that your folder is now included :-

You are now ready to start learning about Powershell and have a folder in which you can place your scripts.

If you do not wish to do this (or perhaps cannot in a business environment) then you can run your Powershell scripts from any directory. You can either insert the full path to your script in with your script name e.g. :-

C:\PScripts\TestScript.ps1

or you can change to the directory that your script is in and put “./”  before your script name e.g. :-

./TestScript.ps1

Notice that all Powershell script files have the extension “ps1” (that’s a number one and not a lower case l).

It’s time to start learning a new language, well sort-of a new language. Windows Powershell 2 (although at the time of writing this Powershell 2 is still in CTP and hasn’t actually been released yet).

You can download the latest CTP 3 from Microsoft here :- Powershell 2 CTP 3

Powershell 2 has many new features and additions from Powershell 1 however depending on the platform that you’re running Powershell 2 on, not all features may be available to you. For example, remoting uses a new WS-Management (which is also in CTP form at present) that is only available on Vista, Windows 2008, Windows 7 and Windows 2008 R2. So although you can run Powershell 2 on Windows XP and Windows 2003, you can’t use all the features that it provides on these platforms.

Some of the new features of Powershell 2 over Powershell 1 are it’s remoting, the ability to run background tasks, a new Powershell IDE environment for entering your scripts, new script debugging features and over 63 new Powershell Cmdlets including one that is very useful, the Out_GridView Cmdlet.

Powershell 2 requires a minimum of .Net Framework 2.0 to be installed on your machine however if you want to take advantage of all of the new features found in Powershell 2 then you need to install .Net Framework 3.5.1 and also the WinRM 2.0 CTP as discussed above.

Installing Powershell 2 is as simple as downloading the MSI file, double clicking on it and running through the wizard.

After the initial splash screen, click to accept the software license.

and click install :-

If you have a previous version (Powershell 1) already installed on your system then you will run into the following dialog :-

Powershell 2 replaces Powershell 1 and you can’t have both installed on your system at the same time. Hopefully by the time Powershell 2 gets released it will automatically do an un-install of previous versions for you so that you don’t need to manually un-install previous versions.

In order to un-install a previous version you need to have the Show Updates checkbox checked (or View Installed Updates if running Vista for example).

Once installed there is a little bit of configuration work that you may want to carry out. By default Windows Powershell 2 has 3 modes of operation

• AllSigned – Only permits scripts that have a trusted signature to execute on your computer
• RemoteSigned – Permits Powershell scripts downloaded from the web to run only if they are from a trusted source
• Unrestricted – Allows any Powershell script to run on your system

By default Powershell 2 runs in AllSigned mode. You can check on this by opening a Powershell and entering the following command :-

get-executionpolicy

If you’re playing with Powershell and learning it’s ropes then you will probably want to elevate the security mode to unrestricted. Please be aware that there are obviously security consideration to take into account here.  To elevate your permissions to unrestricted you enter the following command :-

set-executionpolicy unrestricted

The last thing you may want to take a look at is the script IDE. This is actually called the Windows Powershell ISE (Integrated Scripting Environment)

It’s not as advanced as Visual Studio but it does allow for entering your scripts with TAB completion, debugging and a number of other features.

You now have your basic environment setup and are ready to start learning Windows Powershell 2.

It’s time to start learning a new language, well sort-of a new language. Windows Powershell 2 (although at the time of writing this Powershell 2 is still in CTP and hasn’t actually been released yet).

You can download the latest CTP 3 from Microsoft here :- Powershell 2 CTP 3

Powershell 2 has many new features and additions from Powershell 1 however depending on the platform that you’re running Powershell 2 on, not all features may be available to you. For example, remoting uses a new WS-Management (which is also in CTP form at present) that is only available on Vista, Windows 2008, Windows 7 and Windows 2008 R2. So although you can run Powershell 2 on Windows XP and Windows 2003, you can’t use all the features that it provides on these platforms.

Some of the new features of Powershell 2 over Powershell 1 are it’s remoting, the ability to run background tasks, a new Powershell IDE environment for entering your scripts, new script debugging features and over 63 new Powershell Cmdlets including one that is very useful, the Out_GridView Cmdlet.

Powershell 2 requires a minimum of .Net Framework 2.0 to be installed on your machine however if you want to take advantage of all of the new features found in Powershell 2 then you need to install .Net Framework 3.5.1 and also the WinRM 2.0 CTP as discussed above.

Installing Powershell 2 is as simple as downloading the MSI file, double clicking on it and running through the wizard.

After the initial splash screen, click to accept the software license.

and click install :-

If you have a previous version (Powershell 1) already installed on your system then you will run into the following dialog :-

Powershell 2 replaces Powershell 1 and you can’t have both installed on your system at the same time. Hopefully by the time Powershell 2 gets released it will automatically do an un-install of previous versions for you so that you don’t need to manually un-install previous versions.

In order to un-install a previous version you need to have the Show Updates checkbox checked (or View Installed Updates if running Vista for example).

Once installed there is a little bit of configuration work that you may want to carry out. By default Windows Powershell 2 has 3 modes of operation

• AllSigned – Only permits scripts that have a trusted signature to execute on your computer
• RemoteSigned – Permits Powershell scripts downloaded from the web to run only if they are from a trusted source
• Unrestricted – Allows any Powershell script to run on your system

By default Powershell 2 runs in AllSigned mode. You can check on this by opening a Powershell and entering the following command :-

get-executionpolicy

If you’re playing with Powershell and learning it’s ropes then you will probably want to elevate the security mode to unrestricted. Please be aware that there are obviously security consideration to take into account here.  To elevate your permissions to unrestricted you enter the following command :-

set-executionpolicy unrestricted

The last thing you may want to take a look at is the script IDE. This is actually called the Windows Powershell ISE (Integrated Scripting Environment)

It’s not as advanced as Visual Studio but it does allow for entering your scripts with TAB completion, debugging and a number of other features.

You now have your basic environment setup and are ready to start learning Windows Powershell 2.