Since when they announce the Azure Cloud Shell (see post here), I’ve been waiting to use the PowerShell on the Azure Cloud Shell. I’m still growing my learning how to use the Azure CLI, but PowerShell I’ve been using for years, and I feel way more comfortable with it.
So, how I can use Azure Cloud Shell? Just open the Azure Portal, and on the top bar, between the Notifications and the Settings you will find the Azure Cloud Shell icon .
When you click on the icon, it will ask you to configure the Azure Cloud Shell. The process will provision machines, where you can run the shells (Azure CLI and Azure PowerShell). It’s a fairly simple process. Just follow the steps below.
- Choose what is your Shell of choice. It doesn’t matter if you choose Bash or PowerShell. You can always switch back and forward after the initial setup.
- Choose what is the subscriptions that you want to use. Then you have the simple option of creating the storage or click in Show advanced setting. In this case I opt for the advanced settings.
- On the Advanced setting, you can specify the Resource Group, Storage Account and File Share names that you want to use.
NOTE: Just remember that you have to follow the requirements how to create storage account and file shares (small caps and alphanumeric characters).
- In this case I select the Bash. After I click create, starting to provision the machines. First create all the resources from the previous step.
- After the creation of the resources, it’s connecting to the Bash terminal.
- And that is the end! Now you can start to use the Azure CLI on the Azure Portal.
Changing to PowerShell (or Shell)
After you create the Azure Cloud Shell, you can switch from Bash to PowerShell and vice versa. To do that, just follow the steps:
- Click on the Shell that you are using. In this case I was using Bash. When you click the drop box, you will see the other Shell.
- Select the Shell that you want. In this case PowerShell, then click Restart.
- After that, the Azure Cloud Shell is shutdown the previous Shell and it will restart on the new Shell (even if you never use it before).
- Now it’s creating all the resources required for the first use.
- After the creating of all the resources, it will connect to the terminal.
- Finished! Now you can you use the PowerShell on Azure portal.
Because you are login at the Azure Portal, you don’t need to run the PowerShell command Login-AzureRm. You can start from there.
On the previous post (see here), I create the Recovery Service vault that is required to configured the Site Recovery infrastructure to protect the workloads, in order to have a Disaster Recovery solution within Azure. In the post, I will show how you can protect your workloads (Azure VMs) from one region into another region.
First step is to prepare the infrastructure. Azure Site Recovery have many scenarios that you can protect the workloads, but in these case, I will only cover the Azure VM protection to another region.
As mention on the previous blog post, my workloads are running on the West US 2 region. After creating the Recovery Services vault on East US 2 region, I need to prepare the infrastructure.
To step up the infrastructure follow the steps:
- On the Recovery Services vault, click on Site Recovery, under GETTING STARTED
- It will open another blade. Click on Prepare Infrastructure
- Select Azure – PREVIEW, under Where are your machines located?
- Make sure that you select To Azure on Where do you want to replicate your machines to?
- Click OK
- Fill all the details required:
- Source Location – is the region where your workloads are running
- Azure virtual machine deployment model – make sure that you select Resource Manager
- Source resource group – is the recourse group where your workloads are running
NOTE: If you have more than one resource group on the same region, you must run this setup again, to add more workloads located on another resource group.
- Click OK to proceed
- Select the workloads that you want to protect.
- Click OK
- On the Configure settings blade, click Create target resources button to conclude the preparation of the infrastructure.
NOTE: Under Target location, by default choose the location where you create the Recovery Services vault, although you can select another region where do you want to replicate too. It’s not recommend that you choose the location where your workloads are running.
- If you do want to change the default settings, then you can click on Customize. Otherwise you can skip to the last step.
There are two different settings that you can customize:
- Resource group, Network, Storage and Availability sets – On this setting you will configure witch resource group, network, storage account and availability set your workload will run, when your failover the virtual machine.
- Replication policy – is where you change the name of the replication policy, RPO and the frequency of the replication.
- If you want to change any of the following setting:
- Target resource group – This is the Resource group where your workload will run in case of failover. On the drop down, list you will see only the resource group available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
- Target virtual network – This is where you can define witch network your workload will run in case of failover. On the drop down, list you will see only the networks available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
- Storage accounts
- Target Storage – This is where your workload will be replicated too. On the drop down, list you will see only the storages accounts available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
- Cache Storage – This is where your workload will be replicated too. On the drop down, list you will see only the storages accounts available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
- Availability sets – This is availability set that your workload will be running in case of failover. On the drop down, list you will see only the availability sets available on the region that you previous select. Although you can either create a new (by default), use an existing one or choose not to set an availability set (Not Applicable option).
- After you change the settings that you want, click OK
- If you want to change the policies setting, these are your options:
- Choose by creating a new policy or an existing one.
NOTE: If you are running these for the first time, it’s recommended that you create a new policy. Although if you are running for the second or more times, you can either choose an existing policy (if the settings are the same) or create a new policy, if the settings are different. It’s not recommended that you create new policies with the same settings.
- Name – This is where you can change the name of the policy
- Recovery point retention – This is where you can configure how long do you want to keep each recovery point.
- App consistent snapshot frequency – This is where you can choose the frequency of the replication.
- After you change the settings that you want, click OK
- Click Enable replication button, to start the workload protection.
- After the configuration is done. Azure will start to replicate the workload from on region to another. The time of the replication it will depend on the size of the disks attached to the workload.
All this process is live. That means you don’t have any downtime while Azure is doing the initial replication.
We know that in the Public Cloud, special Azure, we are cover by the SLA. Although some organizations like to be redundant where it comes to critical workloads. In this post I will cover how you can setup a Disaster Recovery solution within Azure.
In this case I have all my critical workloads running on West US 2 region and the East US 2 is my disaster recovery site.
The first step is to create the Recovery Vault. The Recovery Services Vault is feature inside Azure that makes everything work, as also known by Azure Site Recovery. You can have as many Recovery Services Vaults as you want. Each Recovery Services vault will have its own storage account associated, that means if you create more than one Recovery Service vault you will have more than one storage accounts.
When you create a Recovery Services vault, you need to choose the region where you want to store those workloads. That means the Recovery Services vault is acting as your destination, because of this it’s not recommended to create on the same region that your workloads are running.
To create the Recovery Services vault, follow the steps:
- Click on the Create Recovery vaults button
- Insert the following details
- Select the subscription that you want to create the Recovery Services Vault
- Create or Select an existing Resource Group
- Choose your location (this need to be a different region of the workloads that you want to protect)
- Click on the Create.
- After the creation of the Recovery Services vault, you just create the infrastructure require on Azure to setup all the services need.
There are some considerations when you create a Recovery Services vault to protect you workloads within Azure (this considerations are only for this scenario).
- At this present moment, you only create the infrastructure that supports Azure Site Recovery and Azure Backup. You are not done yet. The next step is to configure either or both services (Site Recovery and Backup).
- If you want to use the Recovery Services for Site Recovery, you need to prepare the infrastructure that will support that. In this case, you need to decide what type of workloads you want to protect from where to Azure. If you want to protect workloads within Azure (i.e between regions), your source workloads (where they are running) should be in a different region. For optimal utilization try to use the “direct” DR Azure site (EastóWest or North óSouth).
- You can protect different regions to the same Recovery Service vault. Although the workloads should not be running on the region, that your Recovery Services is created.
- You don’t need to setup any VNet-to-VNet between the regions. Recovery Services uses the backbone of Azure, to connect to the workloads that you want to protect.
I’ve been deploying to Azure a lot of resources, one of my favorite things is to create templates where I can reuse for other situations. But sometimes, and in some situations, you need to increase the security. That is where I started to leverage the Key Vault to store my secrets.
Over the years, I have been creating a linked template reference where the main template passes parameters and the key vault references to the linked template. Although the template is uploaded to a storage blob container.
Let me exemplify. Imagine that you have the following scenario, you want to leverage the Azure Portal to deploy ARM Templates and you want to use the Key Vault to store the secrets. How I can do it? Although, your Manager concern is, since the URI is public how I can protect the storage container?
The way that I have been getting around on this situation is using private blob storage in conjunction with SAS.
Step 1 – Use Azure File Copy to copy your template to the storage account. Azure File Copy will give you a SAS token. Then use the token to deploy.
Step 2 – On Azure Resource Group Deployment, you have an option to override the template parameters.
Step 3 – You only need to append the SAS token to the final URL.
If you are like me that like to have all the tools on your desktop/laptop, special the Azure PowerShell module, now your live is way easier. Not long time ago, you had to download the Azure PowerShell module through the Web Platform. But now, there a simpler way.
I found this when I need to replace my Surface Pro. Through PowerShellGet module, all the modules related to Azure are on GitHub, so it is way simpler to get always the most update version of the cmdlets to manage Azure. The PowerShellGet comes on Windows 10. To verify if you are running the most updated version, run the following cmdlet:
Get-Module PowerShellGet -list | Select-Object Name,Version,Path
You should get an output like this:
To install all the Azure Resource Manager modules, just follow the steps and you will all the magic happens.
- Open an PowerShell session with elevated privileges (Administrator mode)
- Run the following command
Install-Module AzureRM -AllowClobber
Note: by default, PowerShell Gallery is configured as untrusted repository, so you have trust in this repository to be able to install the Azure RM module.
- Answer Yes or Yes to All on the output of the command to be able to continue the installation
- Just watch the progress bar finishes
- Import the Azure RM module, by running the command
To verify if the install was successful, you can use the following command:
Get-Module AzureRM -list | Select-Object Name,Version,Path