Tag: ARM

Connect Azure VMs to Log Analytics (OMS) via ARM Portal

October 2, 2017October 2, 2017 · 2 Comments ·

Let’s say you have a bunch of machines in Azure, and want them communicating with Azure Log Analytics (aka OMS). Well, I am pretty sure that last thing you want to do is deploy the Microsoft Monitoring Agent to each machine, manually…

Well, now you can connect a VM to Log Analytics (OMS) with just a few clicks.

Go into the ARM (Azure Resource Manager) portal, and navigate to your “Log Analytics” blade, select your OMS workspace name, and within the Workspace Data Sources, select Virtual Machines.

Here you should have your machines that currently live within Azure. As you can see, there is one machine that is not connected to the OMS workspace. Let’s connect it now.

Select the VM in question, and you will now be presented with the following:

Make sure the VM is online/running, and select Connect. The VM must be online in order for the extensions to be passed through.

Give it a few moments, and there we go! No manual agent deployment.

We can also verify now in OMS, to see our new machine chatting with Log Analytics. (Go into the Agent Health solution/title)

How to upload Custom Images to Microsoft Azure using PowerShell

March 10, 2017March 11, 2017 · 2 Comments ·

In this post, I am going to show how to upload a custom image used in Windows Hyper-V (2016) to Azure cloud. I will be using a combination of the UI in Hyper-V and PowerShell in Azure Resource Manager. I will be working with Azure Resource Manager (ARM) and with Hyper-V 2016 with a custom image of Windows Server 2008 R2 SP1.

Okay, let’s get started.

Prepare On-Premises Virtual Machine Image

First, we need an image to work with. As mentioned, I am using a Windows Server 2008 R2 SP1 (yes, 2008 — needed it for a customer). The VM is Generation 1, which is not only a requirement for Windows 2008, but also a requirement for Azure, as it currently does not support Generation 2 VMs. See HERE to read more on preparing a Windows VHD.

Next, we need to install Hyper-V role on the VM. Since this is a nested VM, we will first need to enable nested-virtualization on the Hyper 2016 box. See a previous post on how to go about this HERE. Once that is complete, go ahead and install the Hyper-V role.

Next, we now need to SysPrep our VM. From an Administrative command prompt, navigate to %windir%\system32\sysprep and then execute the command “sysprep.exe”. Here, we will be using OOBE and enabling “Generalize”, also “Shutdown” the VM once SysPrep completes.

Once the VM is SysPrep’ed, we now need to compact the VHDx (remember Hyper-V 2016 here) and also will need to convert the VHDx to a VHD. This is due to the limitation of Azure at the moment, as it only supports Gen1 VMs and VHD’s.

Go into Hyper-V and within the VM properties, edit the Virtual hard disk. Then we will need to compact the virtual hard disk. Go ahead and do that..

Great, now we need to convert the VHDx to a VHD. Time for PowerShell!

Convert-VHD –Path “<source VHDX path>" –DestinationPath "<destination VHD path>" -VHDType Fixed -Verbose

Let this run (I let it go over night.. it was getting late =) )

Great, now we are ready to move on to Azure and more PowerShell.

Build Azure Container and Upload Image to Azure

First, we need to download and install the latest AzureRM bits module locally to the Hyper-V box (if you have done this.. jump down a few lines…)

Install-Module AzureRM -Force

Next, since there was a recent update to the AzureRm module, I now need to update the module path location.

$env:PSModulePath = $env:PSModulePath + "; C:\Program Files\WindowsPowerShell\Modules"

Next, we will need to import the AzureRm module.

Import-Module AzureRM -Force

Next, we’ll need to log-in into our Azure account, and specify the subscription to want to work with. In my case, there are multiple Azure subscriptions tied to my email.

Login-AzureRmAccount
Get-AzureRmSubscription
#select the subsciption you will be working with -- if you have one, you can skip this line
Select-AzureRmSubscription -SubscriptionId "<ID>"

Next, we will create a resource group and storage account, and bind the account the group.

New-AzureRmResourceGroup -Name "ResourceGroupName" -Location "Canada East"
New-AzureRmStorageAccount -ResourceGroupName "ResourceGroupName" -Name "StorageAccountName" -Location "Canada East" -SkuName "Standard_LRS" -Kind "Storage"

If you want to change the storage type, to let’s say Geo-redundant, here are the other types of storage:

Valid values for -SkuName are:

Standard_LRS – Locally redundant storage.
Standard_ZRS – Zone redundant storage.
Standard_GRS – Geo redundant storage.
Standard_RAGRS – Read access geo redundant storage.
Premium_LRS – Premium locally redundant storage.

Now, we need to create a Container and grab the URL needed to upload our image. I did this through the Azure Resource Manager (ARM) Portal since I couldn’t figure out the PowerShell cmdlet (Get-AzureStorageBlob) — if you can get this to work, please let me know!

You can get the URL from the Web UI when you go into the Storage Account >> Blobs >> Container (in my case, I called it “VHD”) >> Properties.

Now we are ready to upload our image/VHD to Azure! For me this took about 2 hours, uploading a 80GB file @ 9-10MBs.

$rgName = "ResourceGroupName"
$AzureVHDURL = "URL"
$LocalVHDPath = "LocalPathtoVHD"
Add-AzureRmVhd -ResourceGroupName $rgName -Destination $AzureVHDURL -LocalFilePath $LocalVHDPath

Great, now we just need to register the VHD disk to the Gallery, and we can begin creating machines based off our image that is now in the cloud! — Another post! 🙂

Issues with Azure Active Directory and Login-AzureRmAccount

January 16, 2017January 20, 2017 · Leave a comment ·

If you’re like me, you have probably banged your head against the wall a few times with the Login-AzureRmAccount cmdlet… I reached out to the Azure Development team and not only is this a known issue, but there is currently no solution at the time…. Hmm.

Here is a bit of the background story, followed with the problem and solution to the issue.

Background:

Using PowerShell to script an auto-login to Azure, and start (and shutdown) Virtual Machines (yes, OMS Automation could help/solve this, but in this scenario my customer is currently not on-board with OMS). At any rate, the script is designed to capture some data on a on-premises server, if the threshold breaks, then begin starting resources in Azure, likewise, if the threshold falls back then shutdown those same resources in Azure.

Problem:

Running the following code, I keep getting the a null entry for SubscriptionId and SubscriptionName. Even though the user I have created is a co-administrator and has access to all the resources necessary. Assuming the login did work and the data isn’t needed…when try to start my Azure VM I get an Azure subscription error. So, let me check the subscription details. Well, there we go, I get the following response, “WARNING: Unable to acquire token for tenant ‘Common’” ….. So what gives?

I check and confirm the test-user is in-fact an administrator in ARM (Azure Resource Manager):

Solution:

Turns out, the user account created, not only needs to be created and added to the resources with Azure Resource Manager (ARM), but also needs to be assigned as an Administrator within Azure Classic Portal.

Once the test-user was added within the Classic Portal Administrators and set as Co-administrator, I could then get SubscriptionId and SubscriptionName info populate, and Get-AzureRmSubscription with proper details. Yay! (Still get that tenant ‘Common’ warning however…)

Now I can go ahead with my script!

I hope this helps you as much as it helped me.

Step-by-Step: Setup and Configure Azure Site Recovery (ASR) with Windows Server 2016 Hyper-V using ARM

December 6, 2016 · 1 Comment ·

Not too long ago, Microsoft announced the support of Windows 2016 and Azure Site Recovery (ASR). Microsoft’s announcement can be found HERE.

With that said, I decided to setup ASR with my Hyper-V 2016 environment. Rather than the typical blog posts (screenshots etc.,) I decided to create a step-by-step video that demonstrates how to setup ASR with Windows Server 2016 and Hyper-V. That video can be found HERE at Channel 9.

In addition this post is a series of blog posts for Azure Site Recovery (ASR).

ASR for Hyper-V 2012R2 On-Premises
ASR for VMs being hosted within Azure
ASR for VMs being hosted On-Premises
ASR for an ESXi hosted On-Premises, coming soon…

Step-by-Step: Setup and Configure Azure Site Recovery (ASR) for On-Premises Hyper-V Host with Azure Resource Manager (ARM)

November 14, 2016August 27, 2018 · 6 Comments ·

This post is a series of blog posts for Azure Site Recovery (ASR).

Here is a step by step walk-through on how to go about setting up and configuring ASR (Azure Site Recovery) and backing up your On-Premises Virtual Machines (VMs) with Azure Resource Manager (ARM).

First things, first, Azure’s Recovery Service Vault is a unified vault/resource that allows you to manage your backup and data disaster recovery needs within Azure. For example, if you are hosting your VMs on-premises you can create a link between your on-prem site and Azure to allow your VMs to be backed-up into Azure. This is regardless of your hypervisor, it can be either ESX or Hyper-V, either will work. However for the interest of this blog post, I will be setting up ASR for a Hyper-V 2012R2 host.

Configuring Azure

Step 1: Create a Recovery Services Vault

Within Azure Resource Manager (ARM), if we select New, within the Marketplace, select Monitoring + management, then select Backup and Site Recovery (OMS) within the featured apps. Of course if this is no longer present, just search for it within the marketplace.

Next we will now need to create our vault.

Give it a meaningful name, and you can either create a new Resource Group, or use an existing. I opted with existing, as I will (another post) next setup a Site-to-Site ASR.

Give this a few seconds, maybe minutes to do its thing…

Great, now our Vault is up and ready to go!

Step 2: Choose your Protection Goal(s)

Click Settings > Site Recovery (Under Getting Stated) > Step 1: Prepare Infrastructure > Protection Goal > And specify the following > Click OK:

Replicating to: Azure
Machines Virtualized: Yes, with Hyper-V
Using SCVMM (Virtual Machine Manager): No

Step 3: Setup the Source Environment

Next, we will now need to Prepare our source give our Hyper-V site a name, “Ravi-OnPrem” makes sense here, but give it something meaningful.

Now we need to download the ASR Provider Installer, along with the Vault Registration Key.

Step 4: Install and Configure the ASR Provider on Hyper-V Host

This Hyper-V host is not behind any Proxy…

If we go back to Azure, we can now see our Hyper-V host populated.

Step 5: Create a Replication Policy

Within our Vault properties > Settings > Manage: Site Recovery Infrastructure > For Hyper-V Sites: Replication Policies > +Replication Policies

Step 6: Associate Hyper-V Site(s)

Next we will need to Associate our Hyper-V site:

Great! Now we can continue on with Step 3 (Target Environment) of Step 1 (Preparing Infrastructure).

Step 7: Create a Storage Account + Virtual Network

Within the Replication, we have a few options here. I left mine as default (GRS) Geo-Redundant.

Next, we need to create a Target Virtual Network:

Now we can go ahead and setup the replication settings:

Step 8: Setup Replication Settings

Since we create the Replication Policy beforehand, this auto-filled. Next we need to do some Capacity Planning. Since this is simply a walk-through example, I elected to skip this, but for a real-production environment, I would highly recommend doing this.

Here is a link to Microsoft’s Capacity Planner for Hyper-V Replica.

Hit OK, and now we are ready to to move on to Step 2 (Replication Application)

This all should have populated since we created our Storage account and Virtual Network just earlier… If not, add them.

Now Azure should have connected with our Hyper-V host, we can now see our VMs within our Hyper-V host. Here we now need to select which machines we will want to include within ASR. For simplicity and variety, I am going to select a domain controller and a Linux machine.

Now we need to configure the VMs properties:

Once we are good, we can go ahead and apply the Replication Policy to our VMs.

Once satisfied, go ahead and hit “Enable Replication“.

Lastly, Step 3, we now need to complete creating our Recovery Plan:

Step 9: Create Recovery Plan

Great! All done? Before we say all done, let’s go back to our Hyper-V host, and configure the Network/Throttling bandwidth.

Step 10: Network/Throttle Bandwidth

My Hyper-V host is not equipped with a GUI as I am using Windows 2012R2 Minimal Server, so navigate here to launch the Microsoft Azure Backup Agent, “C:\Program Files\Microsoft Azure Recovery Services Agent\bin\“. Launch, “wabadmin“.

In the Actions pane, select “Change Properties” >> Select the Throttling tab.

Change these settings as to your needs. I wanted to increase my non-work hours to 4MB, but looks like 1MB is the max.

Great! Since we already hit, enable replication, this process should have already started… Let’s go back to Azure:

If we take a look at the Vault > Settings > Protected Items > Replicated Items

Once these VMs are 100% Synchronized, the next steps will be to simulate a fail over, both Test and Planned.

Step-by-Step: Setup and Configure Azure Site Recovery (ASR) for On-Premises Virtual Machine with Azure Resource Manager (ARM)

November 7, 2016November 1, 2016 · 3 Comments ·

This post is a series of blog posts for Azure Site Recovery (ASR).

ASR for VMs being hosted within Azure
ASR for a Hyper-V hosted On-Premises, coming soon…
ASR for an ESXi hosted On-Premises, coming soon…

Configuring Azure

Step 1: Create a Recovery Services Vault

Next we will now need to create our vault.

Give it a meaningful name, and you can either create a new Resource Group, or use an existing. I opted with existing, as I will (another post) next setup a Site-to-Site ASR.

Give this a few seconds, maybe minutes to do its thing…

Great, now our Vault is up and ready to go!

Step 2: Choose your Protection Goal(s)

Click Settings > Site Recovery (Under Getting Stated) > Step 1: Prepare Infrastructure > Protection Goal > And specify the following > Click OK:

Replicating to: Azure
Machines Virtualized: Yes, with Hyper-V
Using SCVMM (Virtual Machine Manager): No

Step 3: Setup the Source Environment

Next, we will now need to give our Hyper-V site a name, “Ravi-OnPrem” makes sense here, but give it something meaningful.

Once validated, we can now go ahead with the Azure Backup Agent. Download the Azure Backup Agent, and also, download the Backup Credentials.

Download the Agent and Credentials to the server you will be backing up. In my example, I will be backing up a Windows Server 2016 (RTM).

Step 4: Microsoft Azure Recovery Site (MARS) Agent Install

The Microsoft Azure Recovery Site (MARS) Agent is a pretty simple install, but here is what I experienced when installing:

Since my environment is pretty open, ie. No Proxy, no changes required here.

Your call here..

All good with the MARS prerequisites… Hit Install!

All good, time to register our server to our Recovery Services Vault.

Step 5: Register Server to Azure Recovery Services Vault

Here is where we will need that VaultCrentials file.. I hope you downloaded it as mentioned earlier… As you can see, back in the first few steps, when we created our Vault, the settings are now automatically inputted.

Here, I decided to let the wizard generate the Passphrase. I then saved the key locally to the server.

Perfect! Now we can go ahead and with the Azure Back: Site Recovery/Backup Schedule, etc.

Step 6: Configuring Microsoft Azure Backup

Going back to our On-Prem server, which by the way is a Windows 2016 OS, let’s launch Microsoft Azure Backup…

Click on Schedule Backup within the (Right) Actions Pane:

Since this is a basic server, I only allocated 1 drive for this example, once we hit Backup, I am presented with the available drives.

Now we can begin defining our Backup Schedule

Step 7: Specify Backup Schedule

For this example, I want to back up the following server with the following properties:

Backup once a week @ 4AM, every Monday

Retention Policy will be as follows, see below:

Once you are satisfied with the policy, go ahead and hit next. Since we want to back up to Azure, and not an offline backup, we will backup over the network.

Have a look over before we do the initial backup.

Step 7: Initiate Backup Now

Going back to the main console, within the right pane, within Actions, let’s initiate our Back Up Now.

If we now double click within the job, we can see the Backup has begun….

Step 8: Validate Backup

If we go back to Azure, and take a look at our Vault properties, we can see there is a Backup in progress.

If we drill down within the Backup, we can see our server being backed-up.

After a few minutes, we can go back to the server, and track its progress:

And likewise, if we go within to the Azure Resource Manager, and within the Vault Backup jobs, and take a look at the details, we can see data is being updated to Azure.

Perfect!

Step-by-Step: Setup and Configure Azure Site Recovery (ASR) Virtual Machines (VMs) in Azure with Azure Resource Manager (ARM)

October 31, 2016November 1, 2016 · 5 Comments ·

This post is a series of blog posts for Azure Site Recovery (ASR).

ASR for VMs hosted On-Premises, coming soon…
ASR for Hyper-V hosted On-Premises, coming soon…
ASR for an ESXi hosted On-Premises, coming soon…

Configuring Azure

Step 1: Create a Recovery Services Vault

Next we will now need to create our vault.

Give it a meaningful name, and you can either create a new Resource Group, or use an existing. I opted with existing, as I will (another post) next setup a Site-to-Site ASR.

Give this a few seconds, maybe minutes to do its thing…

Great, now our Vault is up and ready to go!

Step 2: Backup Goal/Target

Select +Backup, and let’s setup create a backup strategy:

As mentioned, in this walk-through, we will be setting up ASR for our VMs within Azure. So, this workload will be running against our Azure environment, and we want to backup our VMs.

Step 3: Create a Backup Policy

Now we want to create a backup policy. You can chose the default, which I believe is a daily snap-shot and the retention is 30 days. This may be too aggressive, or too conservative. Nevertheless, let’s create our own.

Give it a name “ASRBackup14Days“, for this example, I want to backup my VMs in the following manner:

Backup every day @ 2AM
Retain the daily backup of the VM for 2 weeks (14 days)
Retain the weekly backup of the VM for 2 weeks
Retain the monthly backup of the VM for 2 months (~60 days)
Also, begin this policy the first day of January 2016…

Of course these options are..optional, you only need to specify either the daily, weekly or monthly retention…

Once complete, we now need to select the VM(s) we would like to back-up.

Select one, or select them all, but keep in mind, this could get costly $$$$, more VMs and more often the back-up frequency.

Step 4: Initial Backup

Great! Now, Enable backup. Now, if we go back to our ASR Vault, should see a job already in progress, as Azure already started the initial backup.

As you can see, the VM is being backed up now!

Step 5: On-Demand Backup

If you ever want to do an ad-hoc backup, just go back to the ASR Vault, within the Protected Items, select the VM(s) you are interested, and schedule an immediate backup.

Creating a Site-to-Site (S2S) VPN with Azure Resource Manager (ARM) and Windows 2012R2

September 19, 2016September 29, 2016 · 8 Comments ·

To begin, I am setting up a Site-to-Site VPN (Virtual Private Network) between my home-lab and Azure. The same concept(s) can be applied to an On-Premises/Data-Center environment and enterprise grade firewalls/routers.

For starters you will need to know the IP of your home network, my IP is dynamic, so it is continuously changing. If you don’t know your public IP, go HERE to get that now. Also, I will be using the Azure Resource Manager portal, and not the classic portal, and lastly working with IPv4, not IPv6. Lastly, I am going to assume you already know a few things about Azure, Windows Server 2012R2 RRAS (Routing and Remote Access Service) and the basics of Networking.

This setup consists of 2 steps — Step 1, setting up and configuring Azure, and Step 2, setting up and configuring your Windows RRAS server. Let’s begin:

Setting up/Configuring Azure:

Step 1: Create a Resource Group

Step 2: Create a Virtual Network

Now we need to create a Virtual Network. This virtual network will provide IPs to machines assigned within this resource group. The IP spacing can be whatever you choose, however it is best to choose an address space different from your home-network. I have chosen a 172.10.0.0/24; my home network is a 10.10.10.0/24.The resource group will always the one you created back in Step 1.

Next I will add two subnets, one for the back-end and one for the gateway of my servers. Within your Virtual Network, select Subnets, and add as many subnets as needed.

Step 3: Create a Virtual Network Gateway

Next we will create the Virtual Network Gateway. The virtual network gateway will be responsible for sending and receiving data. Essentially the bridge between (gateway) Azure and your RRAS server/home-network.

I have kept the defaults, VPN as the Gateway type, and Route based for the VPN type. The resource group will always the one you created back in Step 1.

Depending on your environment and requirements, you will need to decide which VPN type is best for you.

Route based, will support dynamic routing and support multiple VPN connections, using IKEv2.
Policy based, will support static routing, supporting a single VPN connection, and will use IKEv1.

The Virtual Network will be what we just created in Step 2,
The Public IP address will be one of Azure’s Public IPs,
Gateway type will be VPN,
VPN type will be Route based.

Once you have entered all the properties successfully, it will take about an hour for Azure to create the Virtual Network Gateway. (Good time for lunch/a break)

Step 4: Create a Local Network Gateway

Now we need to create the local network gateway, this gateway will be configured with all of your on-premises network.

IP address will be the IP address of your VPN endpoint, ie. Public Facing IP
Address space will be the address space you are using on-premises, in my case my home network is on a 10.10.10.0/24 network. (If you have multiple address spaces on-premises, then add them all here (only add if you want a machine in that space to be Azure accessible))

Keep in mind, the address space here MUST NOT overlap with the address space in Azure (this is why my Azure Local Network was provided a 172.10.0.0/24 address space to differentiate)

The resource group will always the one you created back in Step 1.

Step 5: Create the VPN connection

Now that all the fun stuff is done, now we need to create the VPN connection. Within the Local Network Gateway we just created (Step 4) go within the Connections, and configure a VPN connection.

You will need to specify the Virtual and Local LAN gateways we created in Step 3 and Step 4, for the Virtual Network Gateway and Local Network Gateway, respectively.
The Shared key (PSK) will need to be a string that will be used between the VPN connection and your RRAS server to encrypt and authenticate. I used a password generator with 32 characters, and only used letters and numbers (no special characters). Make sure to save this key, because you will need it in the Windows RRAS setup to complete the Site-to-Site connection!

Great Step 1 – Azure done! After configuring the RRAS server, we will need to come back to Azure, and connect/confirm the VPN traffic is flowing.

Setting up/Configuring Windows RRAS:

Step 1: Install the RRAS Windows Role

Microsoft explains this pretty well and it is pretty straight-forward, so I won’t bother, see HERE.

Step 2: Configure and Enable Routing and Remote Access

Right click on the Network Interface, and select a New Demand-dial Interface

Call it something meaningful…

Continue through the wizard, choose VPN.

Use IKEv2 Encryption here for the VPN Type (as we chose back in Step 5 within the VPN Connection configuration for Azure; they must match…duh)

Here you need to specify the Azure Public IP:

If you don’t know your Azure Public IP, go to your Virtual LAN Gateway, and see within the Essentials properties:

Leave Route IP packets on this interface enabled….

Since we are providing a PSK, credentials here don’t matter.. I just entered, Azure and left the rest blank…

Now add the Static Route for your local network, as mentioned, my network is a 10.10.10.0/24; 255.255.255.0.

Once complete, right-click on the interface we just created, and go to the Security settings. By default “Use machine certificates” will be enabled, select the preshared key for authentication option, and now enter that PSK we used in Step 5 of Azure….

Hit OK, and now let’s try to connect…..

Step 3: Test Connection on Server

Give this a few minutes, I gave it about 5 minutes, and it finally connected to Azure.

Step 4: Establish/Test Connection on Azure VPN

Go back to Azure, and within your VPN connection, hit Connect. For me, this took some time. Initially it connects, then fails, and repeats for a few minutes. I’d say after 5 minutes or so, it finally connected and stayed connected! YAY!

vpn_connection_success

After all that, we now have a VPN connection established between Azure and my home network. This is evident as we can see traffic going in and out via Azure’s Gateway! Sweet!!!

(more…)