PowerShell is marching toward one of the greatest scripting and automation tools of all time. It is increasingly important to learn PowerShell if you are working with Microsoft products and surrounding ecosystems. Considering various limitations on the command-line management exposed using MS-DOS, Microsoft started to develop a new approach to the command-line management way back in 2002 and introduced a shell called Monad. It was September 2006 when Microsoft renamed Monad to PowerShell Version 1. Since then, there have been several versions released, and the current stable version is PowerShell 5. Last year, in 2016, Microsoft announced PowerShell Core 6 on GitHub, being not only open source but also cross-platform. This is what will make PowerShell more popular because of its capability to automate things on Linux as well as macOS.

So, where is PowerShell heading from here on? What is the future of PowerShell? Microsoft is aware of the fact that every business will have a cloud-first strategy and a complex infrastructure to manage. Microsoft's initial intention was to ease the Windows-based server administration and maintenance, but now they are strategically moving ahead to make PowerShell as a standard scripting platform for customers so that it can be used on Windows, Linux, and macOS. The open source nature of PowerShell will fuel the PowerShell growth and will help to build the trusted artifact gallery quickly. Businesses will adopt the multi-cloud strategy and there is no single answer of how to best manage multi-cloud. Management is absolutely the secret ingredient for multi-cloud, and there is no common API that is available to manage multi-cloud effectively. Over a period of time, PowerShell will become a mature scripting language to manage the multi-cloud and hybrid environment. And this is one of the biggest intentions of Microsoft, making it cross-platform in the PowerShell Core.

In this chapter, we will learn about the PowerShell cmdlet and how to get help on each cmdlet. We will also touch base on how PowerShell cmdlets are structured. In addition, we will learn about risk mitigation parameters and building your own help for the scripts that you create.

If you are an IT admin or a developer, you will want to learn PowerShell. Learning PowerShell will enhance your ability to manage your entire IT infrastructure. It is a very rich scripting environment, but I do not want you to limit your thinking that it is just a scripting language. First, it can perform the same task on thousands of servers without logging in and help IT admins or developers to keep all the work consistent on all the servers. This is amazing, isn't it? Second, it is also used for task automation. When we think about the server configuration or deployment, we can use PowerShell to do all kinds of things that we want in our environment. Third, it is also object oriented. What I mean here is that everything we do inside of PowerShell is treated like an object, even if the object is a service, process, or just a server. Because of its object-oriented capability, many developers started using PowerShell even though it traditionally looks like an IT admin tool.

Microsoft is putting its full weight behind PowerShell. PowerShell is not going away; it is rather creating a big footprint in the task automation area, as Microsoft announced its intention to make PowerShell open sourced. They know that customers are really having heterogeneous environment in their IT shops, and this is why they thought to make PowerShell available to the community so that it becomes standard for IT automation in data centers. Microsoft also made it mandatory to have a PowerShell support for each product they released. Other vendors such as NetApp, IBM, VMWare, Dell, AWS, and several others have strong support for PowerShell. So, PowerShell is going to stay, and your reward for learning PowerShell is the improved ability to control and automate many technologies that it integrates and works with.

Different versions of Windows come with different version of PowerShell. For example, Windows 8 and Windows Server 2013 have PowerShell 3.0, whereas Windows 8.1 comes with PowerShell 4.0 by default. On Windows 10 and later, you see PowerShell 5 installed by default. For now, we will just focus on running PowerShell on your Windows desktop. I am running Windows 10 at the time of writing this book; thus I will use Windows 10 to demonstrate the concept to know more about PowerShell. At the same time, this chapter is not intended to make you an expert in PowerShell scripting; it is rather to help you know the very basics of the PowerShell environment so that you are all set for the journey that you are planning in this book to learn AWS Tools for PowerShell Core. This would help if you are new to PowerShell. You do not need to be an expert, but understanding the basic commands in PowerShell will help you. If you are keen to learn more about PowerShell, my suggestion is to consider buying other PowerShell-related books or take some online training to gain more insight into this beautiful scripting language.

You only need to type the first few letters of the word PowerShell on the start screen. As we discussed earlier, Microsoft announced PowerShell Core 6, which is still in beta at the time of writing this book. So, I have downloaded the PowerShell Core 6 beta version from the GitHub repository. I will be using PowerShell Core 6 on Windows 10 as we move forward. You may want to pin PowerShell into your taskbar rather than starting this way, by typing in the start screen window every time you run PowerShell:

There are four options that you will see in most of the Windows PowerShell environment. If you see (x86) in the options, such as Windows PowerShell (x86) or Windows PowerShell ISE (x86), it means that it is 32-bit binaries for PowerShell, and without (x86) they are 64-bit binaries available for PowerShell. Windows PowerShell ISE is a nice GUI and an Integrated Scripting Environment (ISE). You can start an ISE environment by clicking on Windows PowerShell ISE ;or by just running the ise command inside PowerShell. The best thing about ISE is that it has a lot of advantages to it. Not only can you see the scripting pane at the top, which allows you to write rich and robust scripts, but you can also have error checks and debugging built into it, so you can step through the script one at a time if you want to do so.

Once you start PowerShell, you can mostly use get-host or $PSVersionTable to check the version of PowerShell. get-host works in all versions of PowerShell, whereas $PSVersionTable works in PowerShell version 2 and later.

PowerShell is a natural language that you can learn quickly. There are four types of commands that PowerShell can run. Those are windows native, aliases, scripts, and cmdlet. Many people think that the only thing that PowerShell can do is run cmdlet, but that's not all true. Certainly, cmdlets are more popular, but in addition, you can run Windows native commands, aliases, and scripts. Cmdlets have a unique structure. There are thousands of cmdlet provided by AWS for managing the AWS infrastructure. Almost all the cmdlets work in a similar way, and this simplifies the scripting. All cmdlets have two parts. The first part is a verb and the second part is a noun. Usually, the verb indicates an action for the command, and the noun indicates a specific service or program. Set, get, add, and remove are some of the most popular verbs that you will see in PowerShell.

General syntax for cmdlet is:

Cmdlet structure: <verb> - <noun>

Dash (-) in between the verb and noun completes the Windows PowerShell command. It is also a PowerShell convention to use singular nouns. While it is not universally applied, if you are not sure whether a noun is singular or plural, go with singular. Let's say, if you want to see list of services running on Windows, then Get-Service is the cmdlet that you can use and not Get-Services:

PS C:\>Get-Service

Note that PowerShell cmdlets are not case sensitive, so if you type Get-Service or get-service in the PowerShell command prompt, both of them are going to yield the same result. You can get the list of common verbs used by PowerShell by running the following:

PS C:\>Get-Verb

This will give you an idea of how many verbs that PowerShell uses.

Microsoft has designed PowerShell in such a way that it is easy to use for complex scripting and automation tasks, and it is also easy to use for an interactive command. The standard naming convention used for a PowerShell cmdlet will assist you in figuring out how to accomplish certain tasks. Understanding the help system capability in PowerShell will help you to write the complex scripting cases in a large infrastructure setup, and the help system in PowerShell will become your most important resource. On some Windows systems, in case you do not find the help system installed, you can update it using the update-Help cmdlet:

PS C:\>Update-Help -Force

Force with Update-Help indicates that the Update-Help cmdlet does not follow the once-per-day limitation; it skips version checking and downloads files that exceed the 1 GB limit. Also, you need to ensure that you started PowerShell as an administrator before attempting to run this command.

The Get-Help cmdlet displays information about the necessary help for any other cmdlet that you need the information for. You can seek help on any cmdlet using Get-Help. For example, if you want to seek information on the Get-Process cmdlet, then you can use the following command:

PS C:\>Get-Help Get-Process

The output shows the help for Get-Process. I would encourage you to check the following commonly used variant of the Get-Help cmdlet, which would feed you more detailed information on the specific cmdlet. This is what will help you to understand the command usage in detail when you start scripting:

PS C:\>Get-Help Get-Process -ShowWindow
PS C:\>Get-Help Get-Process -Detailed
PS C:\>Get-Help Get-Process -Full
PS C:\>Get-Help Get-Process -Online

If you are new to PowerShell, you must be excited to know about all the cmdlets and aliases available. It is an easy language to read and learn. You might want to know how many cmdlets and aliases are out there that you can use in your scripting language. Wait, that's very simple. You can unleash the list of all cmdlets and aliases just using a couple of commands. Get-Command is the cmdlet that will list you all the available cmdlets:

PS C:\>Get-Command

You can further narrow down the discovery using some keyword, and this is major plus point, which lets you quickly search and use the appropriate cmdlet in your script. You do not need to remember any cmdlet; just think of a specific action or service that you want to do, and pass it on to the Get-Command cmdlet to further refine the search. If you want to list all the process-related cmdlets, then you can use this:

PS C:\>Get-Command *process*

Once you see the available list, you can pick up the most appropriate one and get help using the Get-Help cmdlet. This is the best way to learn about various cmdlets. There is nothing like a fixed set of cmdlets available. This list is growing everyday. As and when you add a module, a new set of cmdlets associated with the service or product will be added in the list. Moving further, when we install AWS Tools for PowerShell, a new set of cmdlets will be added, and we will be making use of this new set of cmdlets to work with AWS Cloud.

Another way you can work with commands inside PowerShell is via aliases. Aliases are how you can bridge your knowledge about cmdlets, where you are coming from to where you want to go inside of PowerShell. For example, Get-ChildItem is the cmdlet used for listing all the items in the present working directory, or you can specify the location. If you are a Windows guy, using dir for quite a long time, you may prefer to continue to use this instead of using Get-ChildItem. If you are a Linux guy, then you may prefer to use ls. So, if you type dir, ls, or gci at the command prompt, then all of them will lead to the same result as thrown by Get-ChildItem. Are dir, ls, and gci different commands? The answer is NO. dir, ls, and gci are the aliases for Get-ChildItem. So, if you type Get-Alias in the command prompt, it will list you all the aliases defined in the PowerShell. You can also create your own aliases using Set-Alias. To get the list of existing alias, you can run the following command:

PS C:\>Get-Alias

You can specify the name of the alias with Get-Alias to know the parent cmdlet; for example:

PS C:\>Get-Alias dir
PS C:\>Get-Alias ls
PS C:\>Get-Alias gci

There are thousands of cmdlets available. Don't worry. It's not very scary. Don't think that you need to remember all those cmdlets to be a good IT admin or a developer. I do not know anybody who claims that he knows all the cmdlets. As I said earlier, the number of cmdlets are increasing day by day; what is important to know is how to get help on those cmdlets, discover the cmdlets, and learn the properties associated with specific cmdlets. Let's dive a little deeper into one cmdlet called Get-Service. Now, if you run this cmdlet in the PowerShell command prompt, you find that it returned just three columns.

Does that mean that it has just got three columns? The answer is NO. There are methods and properties associated with each cmdlet. You can learn more about those methods and properties using the Get-Member cmdlet with Get-Service.

This way you can learn about the cmdlet that you plan to use in your scripting. You can now see that there are several properties and methods that you can make use of instead of the default output. Usually, if you are a developer, you will love to know more about the methods so that you can interact with the service using code.

Let's assume that you are interested in Name, Status, and StartType. You can tweak the output now using Format-List or Format-Table cmdlet as follows:

PS C:\>Get-Service | Format-List Name, Status, StartType
PS C:\>Get-Service | Format-Table Name, Status, StartType

PowerShell has two risk mitigation parameters called WhatIf and Confirm. They are very useful for testing complicated scripts without risking the code running amok. By appending WhatIf and Confirm, you get a preview of what could have happened without risking the damage. Let's take a real-life example of a file deletion using a wildcard. Consider that there are some files, and you plan to delete them. But you want to ensure that you are deleting the right set of files that you intend to delete. Because you are using a wildcard, the consequences could be very serious. Hence, it is always prudent to ensure that you are not risking the run of the command. Lets assume that you want to remove file*.txt files from some directory; you can use WhatIf something like following:

PS C:\>Get-Childitem C:\somedata\file*.txt -Recurse | Remove-Item -WhatIf

In the example, we used file*.txt (with a wildcard), and the command did not make any permanent change when you appended the command with WhatIf. The command run is just letting us know that if you run it without WhatIf, it is going to delete all those five files. Likewise, you can use Confirm by appending at the end of the command to get a confirmation if the specific file can be deleted or not:

PS C:\>Get-Childitem C:\somedata\file*.txt -Recurse | Remove-Item -Confirm

These two risk mitigation parameters are really powerful when you start rolling out the script to hundreds of servers, and it will help to ease your anxiety a little bit.

As you work with PowerShell, sending out output and controlling the formatting of the output is very easy. Redirecting output is also a common use of the Pipe (|) operator that you find in PowerShell. There are different ways to deal with the output of the commands. As highlighted earlier, you can use the Format-List and Format-Table cmdlet to get the required properties in the output. In case you want to save the output to the file, you can use the out-file or export-csv parameter with the cmdlet. For example, let's say you want to save the services output to the file, then you simply use this:

PS C:\>Get-Service | out-file C:\services.txt

Or you use this:

PS C:\>Get-Service | export-csv C:\services.txt

One of the best things that you can find in PowerShell is called a grid view. It allows you to output the data to the GUI where you can work with it a little bit easier, especially when you are looking to manipulate data and get a quick peek on what's going on in a particular server or what's happening with a particular cmdlet. Out-GridView offers a great alternative instead of trying to figure out how to output to a file or a different table:

PS C:\>Get-Service | Out-GridView

This will just display the default properties into the grid view and not all the properties. But wait, you cannot combine Out-GridView with the Format-List and Format-Table commands. If you want to control what parameters go into the grid view, then the Select-Object cmdlet is what comes to the rescue:

PS C:\>Get-Service | Select-Object DisplayName,Status | Out-GridView

If you want all the parameters to send to the grid view, then you can use this:

PS C:\>Get-Service | Select-Object * | Out-GridView

If you are looking to get the quick details, then the grid view is the way to go.

One of the advantages of PowerShell is accessing the remote servers. Running commands on remote servers is called PowerShell remoting, and this is not something new. Many IT admins run PowerShell on their client-side desktops and access servers located in different data centers to ease the administrative effort. In the cmdlets, there is a ComputerName parameter that you can use to run the command on the remote server. You just need to ensure that the ComputerName parameter specified is seen on the network and has a remoting option enabled. Let's say you want to run the Get-Service cmdlet on the server called apps1, then you can run this:

 PS C:\>Get-Service -ComputerName apps1

So, all the cmdlets that you run locally can be run on the remote server just by specifying the ComputerName parameter with it.

PowerShell is locked down by default. In order to enable remoting, you have to run the Enable-PsRemoting cmdlet:

PS C:\> Enable-PsRemoting -Force

This command starts the Windows Remote Management (WinRM) service, sets it to start automatically with your system, and creates a firewall rule that allows incoming connections. The Force part of the command tells PowerShell to perform these actions without prompting you for each step. You should restart the WinRM service so that new settings can take effect:

PS C:\Restart-Service WinRM

For testing the connection, you can use this:

PS C:\Test-WsMan <RemoteComputer>
PS C:\Enter-PsSession -ComputerName <RemoteComputer> 

Or you can run any other cmdlet with ComputerName parameter.

When you start building script for automation that can be used by yourself and others repeatedly for doing some task, building parameterized script is the key. In PowerShell, it is very easy to build the parameterized script using just a simple param keyword in the script file. You may have solved the problem using individual cmdlets, and you now want that one to be used repeatedly for building an automation. Let's review the following script for a better understanding of using parameters:

I created a file called DiskInfo.ps1 in the D:\scripts directory. This script provides you with free GB available on the drive that you pass to this script. I am using Get-CimInstance to get me the computer name and free GB. The param keyword at the top of the script can be seen. You might just need to get a feeling of writing that syntax and nothing more. To make the drive letter mandatory, I used a keyword called Mandatory=$true. Once you saved the file, the script can be run as follows:

PS :\D>.\DiskInfo.ps1 -Drive C:

The beauty of the script is that when you start hitting the tab after the script name on the command prompt, it starts displaying you the parameters that can be passed to the script, which is amazing. This is the way you start building a new set of cmdlets for you. There is nothing else that needs to be done to build your own cmdlets.

Another very important thing in PowerShell that you must know is that you can build the script with in-built help. There are no separate files that you need to maintain for your script. This is an amazing capability. There are two ways that you can write help lines in your PowerShell Script. You can either use a hash (#) in the line to indicate it's a help, or you can make use of the <#..#> block level comment. Let's use the following script to continue the discussion:

I specified a block level comment in <#..#> with some other interesting things. Once the parsing engine sees the block of lines inside <#..#>, it starts ignoring the text and knows that it is help comment. But pay special attention to the lines inside that block, which are started with a dot (.). It has a special meaning in PowerShell. PowerShell starts building your help file once it sees this dot. This is extremely helpful in PowerShell when you build a complex script that can be used by others. There is no need to maintain a separate help file. It is just like the help you seek for any other cmdlet available in PowerShell. You can simply now type the following and see the magic:

PS C:\>Get-Help .\PS_Comment.ps1 -detailed

So, you just built a help file that looks like the cmdlet help.

PowerShell is not new. It has been here since 2006, but mostly used in the Windows environment. There have been different versions released until now, the most recent being PowerShell 5 on Windows. PowerShell Core 6 is now an open source project that is being delivered not just on Windows but also on Linux and macOS. PowerShell Core 6 is what Microsoft are planning to support on a multi-platform environment; and at the time of writing this book, it has just been moved from alpha to beta. Looking into future, managing multi-cloud and hybrid heterogeneous environments, Microsoft sees a strong demand for a universal shell to manage the complex IT shops and drive automation. Because PowerShell provides a unified experience and single pane to interact with multiple vendor products, it will be helpful to manage multi-cloud, hybrid, and heterogeneous environments. So, stay tuned and keep learning PowerShell Core 6. In the next chapter, we will review some of the AWS services that we will touch base in rest of the book.