PowerShell is a great automation tool. Don’t you agree? Of course you do. Don’t worry—I can’t read your mind (unfortunately PowerShell can’t help me with that). You are reading a PowerShell book though, which means that you are using PowerShell, so I can guess!

Getting back to our topic, the reason that PowerShell became a first choice very fast is not simply due to the ease of using the language, but also because it is a complete automation platform with a scripting language, a workflows engine, Desired State Configuration (DSC), and so many other features. Also, PowerShell is used in Microsoft and non-Microsoft products. For example, VMware—one of Microsoft’s biggest competitors—uses PowerShell to automate and manage VMware vSphere through the PowerShell management interface known as PowerCLI.

As with almost all Microsoft products that have a PowerShell management interface, Azure PowerShell is a module that comes as part of the Azure SDK. This module has a set of cmdlets that allow you to manage, deploy, and automate different aspects and workloads on Azure. Yet, Azure PowerShell is not the only usage for PowerShell in Azure’s services. In the upcoming chapters, you learn that Azure Automation Services is built on top of PowerShell’s workflow engine.

Also, there is the Azure Desired Stated Configuration (DSC) extension for virtual machines (VMs). DSC is a configuration management platform built in the Windows operating system to define how the Windows OS should be configured in your environment. In other words, DSC is built to allow you to set your own configuration standards for your servers. Starting with version 4.0, PowerShell introduced the DSC language extension so that you can configure DSC using PowerShell, which makes it super easy to build and deploy DSC. The Azure DSC extension for VMs utilizes DSC in Windows along with the PowerShell DSC extension to deploy the desired configuration while provisioning a new virtual machine. So, for example, if you are deploying a web farm that has four nodes, and each node requires Internet Information Services (IIS) to be installed, you can easily achieve this task by using the Azure DSC extension.

In this chapter, you will look at Azure PowerShell, what is required to install it, how to configure it, and, most importantly, how to connect it to your Azure subscription.

Azure PowerShell Jump-Start

The Azure PowerShell module is supported on Windows 7, Windows Server 2008 R2, and newer versions of Windows. It requires PowerShell 3.0 or later, .NET Framework 4.5, and an Azure subscription— so make sure to have these ready before starting.

The Azure PowerShell module is available through the Microsoft Web Platform Installer on the Microsoft Azure web site. To download it, go to the Downloads tab on the Azure home page, or simply go to http://azure.microsoft.com/en-us/downloads/ and scroll down until you find Windows PowerShell, as shown in Figure 2-1. Click Install to get the prompt for saving the file.

Once the download is complete, launch the installer package and follow the setup wizard to start the Azure PowerShell installation. The installation time varies based on Internet connectivity, but it shouldn’t take too much time. Azure PowerShell is part of the Azure SDK, so after finishing the installation, you will find that Microsoft Azure PowerShell has been installed along with other Azure components, as shown in Figure 2-2. We will not use any of these components in this book, but it is always good to know what we have on our machines.

Azure PowerShell is the fastest-growing PowerShell module that I have ever seen, and this has been the case since the release of the first PowerShell version in 2006. There is a new version released nearly every one or two weeks, so keep your eyes on it. Azure PowerShell is an open source project available on GitHub. You can follow this project, get the source code, release installation package, and monitor the different releases and changes in every release.

To update the Azure PowerShell module, launch the Microsoft Web Platform Installer utility on your machine, and then look for the button under the Install column in front of Microsoft Azure PowerShell, as shown in Figure 2-3.

If the button is dimmed with the word Installed inside, then you have the latest version. Otherwise, you have an update if the button is active with the word Add inside.

Now Microsoft Azure PowerShell is successfully installed on your machine. To open it, you can use the Microsoft Azure PowerShell shortcut on the desktop if you have Windows 7; it’s on the Start screen if you have Windows 8 or later.

Also, you can launch either the PowerShell console or the PowerShell ISE to import the Azure module by using the Import-Module cmdlet.

PS C:> Import-Module Azure

You can also keep track of the module’s version by using the Get-Module cmdlet.

PS C:> Get-Module Azure | Select Version

To retrieve all the available cmdlets in the module, use the Get-Command cmdlet with the –Module parameter, and count them using the Count method.

PS C:> Get-Command -Module Azure –Type Cmdlet
PS C:> (Get-Command -Module Azure –Type Cmdlet).Count

If you are using PowerShell 4.0 or a later version, then you don’t have to import the module manually. The reason is that starting in version 4.0, PowerShell supports module autoloading and cmdlets discovery, which automatically discovers all the modules installed on the machine and imports them.

Upcoming Changes in Azure PowerShell

Starting with Azure PowerShell version 0.8.0, the Azure PowerShell module included two sub modules: Azure Service Management (ASM) and Azure Resource Manager (ARM). These modules have a set of cmdlets that target specific Azure REST APIs. The ASM sub-module targets ASM APIs and the ARM targets ARM APIs.

Both modules can be used to create Azure resources such as storage, virtual networks, virtual machines, and so on. Also, both modules have the same cmdlets name but they work in entirely different ways. While the ASM module is for creating and managing Azure resources individually, the ARM module is capable of creating and managing a collection of different resources as a logical group or unit known as a resource group. For instance, with the ASM module you can create a web site, but with the ARM module, you can create a web site along with SQL database in the backend in a resource group and configure an access control list (ACL) for that resource group using Azure Active Directory. Later in this book, we will discuss the Azure Resource Manager in detail. Meanwhile, to understand the essence of ASM REST APIs versus ARM REST APIs, I urge you to visit the Azure Portal (http://manage.windowsazure.com), and the new portal (http://portal.azure.com, still in preview at the time of writing).

The ASM and ARM modules cannot run together in the same session. The main reason for this is that both modules have the same cmdlet names. If you want to use one of them, then you have to unload the other one. By design, the ASM module is the default module. If you want to switch between modules, use the Switch-AzureMode cmdlet along with the module’s name—either AzureServiceManagement or AzureResourceManager.

Starting with Azure PowerShell version 0.9.2, if you are trying to use the Switch-AzureMode cmdlet, you will get a warning message telling you that the Switch-AzureMode cmdlet is deprecated and it will be removed in a future release. This is due to Microsoft making some changes in Azure PowerShell to make it possible to load both modules in the same session. They are also making ARM REST APIs the default in the Azure Portal instead of the ASM REST APIs, and the ARM Module the default module in Azure PowerShell instead of the ASM module.

As part of the change, the cmdlets in Azure Resource Manager (ARM) will be renamed from [Verb]-Azure[Noun] to [Verb]-AzureRM[Noun]. For example, the New-AzureVM cmdlet will become New-AzureRMVM. Also, the ARM module will be broken into modules by services and functionality. For example, AzureCompute, AzureStorage, AzureNetwork, and so on. The new modules for Azure and Azure Resource Manager will be distributed via PowerShell Gallery (http://www.PowerShellGallery.com)

In this book, we cover the ASM and ARM modules side by side in our PowerShell examples whenever possible. Thus, you don’t need to worry about this change in Azure PowerShell.

Getting Azure Ready for PowerShell

After downloading, installing, and importing the Azure PowerShell module, you are very close to completing your PowerShell takeoff toward the cloud. The last step is to set up your PowerShell environment by connecting it to your Azure subscription. Since I mentioned connection, then I must mention authentication.

Azure PowerShell has two methods to get you authenticated. The first option uses a management certificate and the second option uses an Azure Active Directory account. Let’s take a deeper look at each option separately.

Authentication Using a Certificate

In this method, Azure PowerShell uses Azure’s Management Certificate to become authenticated and connect to the Azure subscription. To use certificate authentication, you have to first download the PublishSettings file, which is an XML configuration file that has your Azure subscription’s unique information, such as the service endpoint URL, subscription ID, subscription name, and management certificate thumbprint. This information is used by PowerShell to reach your Microsoft Azure environment.

You can get the PublishSettings file easily by using the Get-AzurePublishSettingsFile cmdlet. This cmdlet generates a new management certificate for your subscription, and then launches the Internet browser, takes you to the Azure portal, and asks you to enter your credentials. Then you are redirected to an instructional page to generate and download your unique Microsoft Azure configuration file, which ends with the .PublishSettings file extension.

PS C:> Get-AzurePublishSettingsFile

The next step is importing it to PowerShell to define your subscription information into Windows PowerShell. To import the PublishSettings file, use the Import-AzurePublishSettingsFile cmdlet.

PS C:> Import-AzurePublishSettingsFile <FileName>.publishsettings

Once the PublishSettings file is imported successfully, Windows PowerShell sets your subscription as a default subscription so that every time you open Windows PowerShell and use Windows Azure cmdlets, it automatically connects to Windows Azure using the subscription defined as the default.

If you have more than one subscription in the PublishSettings file, the first subscription is the default one. You can easily get the list of subscriptions you have by using the Get-AzureSubscription cmdlet, as shown in Figure 2-4.

You can use the Select-AzureSubscription cmdlet to move between different Azure subscriptions.

To change the default subscription, use the -Default parameter.

PS C:> Select-AzureSubscription -Name "MSDN-02" -Default

To change the current subscription temporarily without changing the default one, use the -Current parameter.

PS C:> Select-AzureSubscription -Name "MSDN-02" -Current

Also, you can use the Remove-AzureSubscription cmdlet to remove any of your subscriptions.

Azure PowerShell also allows you to manipulate your subscription by using the Set-AzureSubscription cmdlet. It can be used to add a subscription manually to the local store, or to change the current subscription settings.

One of the most common uses for the Set-AzureSubscription cmdlet is to set up the default storage account for an Azure subscription. By setting up a default storage account, you make things easier for yourself. The next time you create a VM, a web site, or a database, Azure will select it from your subscription settings.

PS C:> Set-AzureSubscription -SubscriptionName "Subscription_Name" -CurrentStorageAccountName "Storage_Account_Name"

In Chapter 3, we will cover in detail the different Azure storage options and the related cmdlets. Meanwhile, for example’s sake, you can use the Get-AzureStorageAccount cmdlet to list the storage accounts you have under a specific Azure subscription, or you can create a new one by using the New-AzureStorageAccount cmdlet (as shown in the following example) until we get to Chapter 3.

PS C:> New-AzureStorageAccount -StorageAccountName "apresspsazure" -Label "apress1" -Location "West Europe"

To verify the new default storage account name, use the Get-AzureSubscription cmdlet one more time.

PS C:> Get-AzureSubscription -Name "Subscription_Name" | Select CurrentStorageAccountName

CurrentStorageAccountName
-------------------------
apresspsazure

Authentication Using the Azure Active Directory

Azure Active Directory authentication is done by using the Add-AzureAccount cmdlet. This cmdlet prompts a login window within PowerShell that asks for a username and password, as shown in Figure 2-5.

To get authenticated successfully, use one of the admin or co-admin accounts stored under your default Azure Active Directory tenant.

Unlike the method that uses a management certificate, Azure Active Directory authentication uses a token that is valid for 12 hours, after which you have to reauthenticate.

What I personally like about using the Azure AD authentication method is it has a -Credential parameter, which means that you can pass a PSCredential object directly to it. However, keep in mind that this feature works only for organizational accounts, not Microsoft accounts.

A Microsoft account (formerly known as Windows Live ID) is the account you create for personal use for a services like Hotmail, Xbox Live, OneDrive, and so forth. On the hand, an organizational account is the account that your company’s administrator creates for you to use Microsoft cloud services like Office365, Microsoft Azure, and Microsoft Intune. The organizational account is usually in the [email protected] format. In Chapter 10, we cover the Azure Active Directory and how to create organizational accounts through PowerShell.

PS C:> Add-AzureAccount -Credential (Get-Credential [email protected])

To list all available Azure accounts, use the Get-AzureAccount cmdlet.

PS C:> Get-AzureAccount | Select Id

After finishing your tasks, you can close the session manually by using the Remove-AzureAccount cmdlet and passing the Azure AD account username to the -Name parameter.

PS C:> Remove-AzureAccount -Name ’[email protected]’

If you try to run any Azure cmdlet after removing the Azure account, you will get an error message, as shown in Figure 2-6.

Congratulations! Your Azure PowerShell environment is ready. It is time to take it to the next level.

Summary

In this chapter, you learned about Azure PowerShell and how to download, install, and configure it.

In the next chapter, you will start your tour in Azure PowerShell land by visiting Azure storage and storage accounts. Azure storage is a core component to most (if not all) Azure services and workloads. You will learn about Azure PowerShell cmdlets for different storage options, which you will practice via sets of basic and advanced scenarios and examples. Get ready for the workout!