Azure PowerShell – Overview

On Windows Server 2008, Microsoft introduces us back to the world of the command line with PowerShell. At the beginning, I must admit, at that time I was a bit reluctant to this command line tool, because I’m a GUI guy! But with time and all my peers tell me the benefits, I slowly start to play with and see the benefits! Now I can’t leave without it!

So, what is Azure PowerShell? Azure PowerShell is a module of the Windows PowerShell that every Windows OS (either client or server) have by default installed and now becomes part of the OS. In this case is to manage Azure!

To manage Azure resources by using Windows PowerShell, you first need to install the Azure PowerShell modules that provide this functionality. The Azure PowerShell modules belong to the following three categories:

  • Azure Resource Manager. A collection of Azure Resource Manager component modules, consisting of cmdlets that implement features of individual Azure Resource Manager resource providers. For example, cmdlets of the Compute provider (which facilitates the deployment of Azure Virtual Machines) reside in the Compute module.
  • Azure Service Management. A collection of cmdlets that implement features of the Service Management model, which is also known as the classic deployment model.
  • Azure Storage. A collection of cmdlets that facilitate the management of Azure Storage.

The two primary methods of installing the latest versions of the Azure PowerShell modules are:

  • The Web Platform Installer (Web PI). This installation method is available directly from the Azure Downloads page. It simplifies the setup process by relying on Web PI capabilities, which include obtaining the most recent version of the installation files and automatically deploying and configuring any prerequisites.
  • The PowerShell Gallery. This installation method relies on the capabilities built in to the PowerShell Gallery, which constitutes the central repository for Windows PowerShell content. It requires either Windows Management Framework 5.0 with Windows PowerShell 5.0 or the Package Management component on systems running Windows PowerShell version 3 and Windows PowerShell version 4. Windows Management Framework 5.0 is included by default in Windows 10, and for earlier versions of the Windows operating system, it is available for download from the Microsoft Download Center. To perform the installation, run the Install-Module cmdlet from an elevated session within the Windows PowerShell console or from the Windows PowerShell ISE console pane. In particular, to install the Azure PowerShell modules from the PowerShell Gallery, run the following commands at the Windows PowerShell command prompt:

Install-Module AzureRM
Install-Module Azure

Note: Web PI installs Azure PowerShell modules within the %ProgramFiles%\Microsoft SDKs\Azure\PowerShell directory structure. PowerShell Gallery–based installations use the %ProgramFiles%\WindowsPowerShell\Modules directory structure. Both installation methods automatically update the $env:PSModulePath variable. However, you also have the option of explicitly importing the Azure PowerShell modules into your current Windows PowerShell session by running the following commands at the Windows PowerShell command prompt:

Import-Module Azure

It is also possible to import individual component modules. For example, to import only the AzureRM.Compute module, run the following command at the Windows PowerShell command prompt:

Import-Module AzureRM.Compute

You can easily distinguish between Azure Resource Manager and Service Management cmdlets because they use slightly different formats. Both types of cmdlets use the verb-noun syntax, but while the noun portions of Azure Resource Manager cmdlets start with AzureRm, the Service Management cmdlets include only Azure (without the Rm string). For example, to deploy a new Azure virtual machine by using Azure Resource Manager, you run the New-AzureRmVM cmdlet. To accomplish the same task in the classic deployment model, you use the New-AzureVM cmdlet.

Azure AD module for Windows PowerShell

If you plan to manage Azure Active Directory (Azure AD) by using Windows PowerShell, you need a separate module intended specifically for this purpose, because this functionality is not included in the Azure PowerShell modules. You can use the Azure AD module to manage objects, such as users, groups, devices, and applications, and other aspects of your Azure AD tenant.



Lets try to understand the Azure Datacenters

You probably see on a Microsoft Azure presentation the slide that shows the footprint of Azure. It seems incredible. Look awesome on the slide, but when you are deploying the workloads and designing the solution in Azure, its where the nightmare starts. Where I should deploy my solution? That is the question that comes to my head when I design a solution.

Usually when I design a solution, I always look to see if that region has the feature that I’m looking for available. That is one of the first thing that I look to see what region I will choose. But let’s understand the Azure regions. Why do I have so many regions?

First let’s look where the datacenters are located. These datacenters, including the newly announced ones, are in the following geographic areas at the present moment:

  • Americas
    • Central US
    • East US
    • East US 2
    • North Central US
    • South Central US
    • West Central US
    • West US
    • West US 2
    • US Gov Arizona
    • US Gov Iowa
    • US Gov Texas
    • US Gov Virginia
    • Canada Central
    • Canada East
    • Brazil South
  • Europe
    • France Central
    • France South
    • Germany Central
    • Germany Northeast
    • North Europe
    • West Europe
    • UK South
    • UK West
  • Asia Pacific
    • Australia East
    • Australia Southeast
    • China East
    • China North
    • Central India
    • South India
    • West India
    • Japan East
    • Japan West
    • Korea Central
    • Korea South
    • East Asia
    • Southeast Asia

Microsoft managed the datacenter that host Azure services throughout the world. Whenever you create a new Azure service, you must select an Azure region to determine the datacenter where the service will run. When you select an Azure region, you should consider where the users of that service are located and place the service as close to them as possible. Some services enable you to serve content from more than one Azure region. In this way, you can serve content to a truly global audience while helping to ensure that a local response gives them the highest possible performance.

A range of architectures that spans several generations and is continually evolving forms the basis of these datacenters. The latest generation of datacenters has as its basis a fully modular design that includes the following features:

  • Clusters of servers are packaged into preassembled units based on shipping containers, enabling clusters that contain thousands of servers to be rapidly provisioned and swapped out.
  • The datacenters include uninterruptable power supplies and alternate power supplies for all components, in addition to backup power that can keep the datacenter running in the event of a localized disaster.
  • The clusters within datacenters are connected by redundant high-speed networks.
  • The datacenters are connected to one another and the Internet via high-speed optical networks.
  • The data within a single datacenter can be replicated to three redundant storage devices and also between pairs of datacenters in the same geographic region.
  • The physical and network security for Azure datacenters meets a range of industry and government standards.

The datacenters are designed to minimize power and water usage for maximum efficiency, including servers and other hardware, cooling, and support operations.

The servers in each datacenter are provisioned in clusters, and each cluster includes multiple racks of servers that run Windows Server. A distributed management service implemented by Azure Service Fabric handles provisioning, dynamic scaling, and hardware fault management for the virtual servers that host cloud services on the physical servers in the clusters.