You are browsing the archive for ARM.

Azure IaaS: Deploying B-series VMs

10:18 am in ARM, Azure, Azure PowerShell, B-Series VMs, IaaS, PowerShell, Public Cloud by Wim Matthyssen

Last week Microsoft introduced the B-Series VM size in preview. These B-Series VMs can run workloads that burst in their performance, but do not need continuous full performance of the CPU. Servers that would be eligible for this new “burstable” VM size are servers with small databases, webservers, development servers, quality assurance (QA) and test servers. But also servers with other workloads that do not utilize the full located vCPUs are grate candidates to benefit and lower costs by using a B-Series VM.

clip_image002

Herby a list of the 6 B-Series VM sizes, which are currently available in Preview in the following Azure Regions (Europe-West, US-West 2, US-East, Asia Pacific-Southeast):

Instance Size vCPU vMemory: GiB Tempory Storage / Local SSD: GiB Max data disks Max NICs Credits banked / hour Max Banked Credits
Standard_B1s 1 1 2 2 2 6 144
Standard_B2s 2 4 8 4 3 24 576
Standard_B1ms 1 2 4 2 2 12 288
Standard_B2ms 2 8 16 4 3 36 864
Standard_B4ms 4 16 32 8 4 54 1296
Standard_B8ms 8 32 64 16 4 81 1944

You can also read more about this new VM size here and find all pricing info

Now I am going to show you how you can deploy a new B-Series VM trough Azure PowerShell.

First, you need to request quota to be able to deploy this B-Series VMs. To do so you should logon to the Azure portal and go to Help + support. To request an increase or to be able to deploy B-Series VMs, select New support request.

clip_image004

You need to create a Quota support case for Cores. So, on the NEW SUPPORT REQUEST page, select Issue type as “Quota” and Quota type as “Cores”. Also, select the Subscription and the correct Support plan. Click Next.

clip_image006

Select Severity “C – Minimal Impact”, Deployment model “Resource Manager” and the correct Location, which in my case is West Europe. Select as SKU Families that requires an increase “BS Series” and set the NEW LIMIT higher than before, for example 15 instead of 10. Click Next.

clip_image008

In the Contact Information blade, select your Preferred contact method, provide a Response time, select your preferred Language and fill in the Contact Information. Click Create to create the new support ticket.

clip_image010

clip_image012

In my case I received an email after the quota was been approved, which normally does not take that much time. So from here we can go further with the deployment.

clip_image014

If you open Azure PowerShell, and run following commands, you can now built a new B-Series VM. You can copy the commands or save them to as a PowerShell script (.ps1). Do not forget to adjust all variables were needed.

clip_image016

clip_image018

Hope this helps you getting started with this new B-Series VMs.

Wim Matthyssen (@wmatthyssen)

Azure IaaS: Troubelshooting Windows Update error 8024402F

3:31 pm in 8024402F, ARM, ASM, Azure, hybrid cloud, PowerShell, Windows Server 2012 R2, Windows Update, WSUS by Wim Matthyssen

 
Last week I was troubleshooting a Windows Update issue at several Azure IaaS VMs for a customer. All those Windows Server 2012 R2 servers were workgroup members and had no Network Security Group (NSG) attached which could block the connection to the Microsoft Update servers. But whenever starting Windows Update the below error was shown after a few minutes.

clip_image002

To get this error fixed I followed the below steps. Be aware that you can retry running Windows Update again after each step because it could be already working again.

 

Step 1

If the server has been configured to use WSUS to get its updates, first wipe out those registry keys by running the below command in a PowerShell window (with admin privileges). Press Y to delete all registry keys when asked:

clip_image004

clip_image006

This also may reset some Windows Update settings, for instance, the one that decides if updates should install automatically or after asking permission.  Therefore, you need to set your preferred settings afterwards.

Check for updates using Windows Update and see if the issue has been resolved, if not proceed to step 2.

 

Step 2

If you still receive the same error, run the following PowerShell Script to rename the SoftwareDistribution and catroot2 folder. These folders, which are maintained by the WUAgent (Windows Update Agent), are essential components for Windows Update. However, sometimes the content of these folders could prevent Windows Update from applying new updates to the server. When having trouble with Windows Update, it is safe to delete this folder. The server will always re-download all the necessary files, or re-create the folder and re-download all the components, if removed.

clip_image008

Now please check for updates using Windows Update to see if the issue has been resolved.

 

Step 3

If step 2 also does not fix the problem, you could try running the below command from an elevated PowerShell window. This command will import proxy information used by Internet Explorer in the Windows HTTP Services (WinHTTP). Several server roles, like the Microsoft Windows Update client, rely on WinHTTP to manage all HTTP and HTTPS traffic. Windows Update uses it mainly to scan for available updates.

clip_image010

 

Step 4

As a last solution, you could try running the Windows Update Troubleshooter tool. To download and startup this tool run the below PowerShell commands.

clip_image012
clip_image014

When the tool opens, go through all steps to get Windows Update fixed.

If all goes well, Windows Update should be working again by the use of one of the above steps. Hope it helps and if you have any questions feel free to contact me through my twitter handle.

Wim Matthyssen (@wmatthyssen)

Azure PowerShell: Migrate an Azure ASM Virtual IP address (VIP) to an ARM Public IP address (PIP)

12:13 pm in ARM, ASM, Azure, Azure PowerShell, Cloud, PIP, Public Cloud, Public IP address, VIP, Virtual IP address by Wim Matthyssen

The last weeks, I am assisting some customers with the migration of their existing Azure Service Manager (ASM) VMs to the Azure Resource Manager (ARM) portal. Most of those workloads are migrated with the use of Azure Site Recovery (ASR). The only thing ASR cannot handle for the moment is the migration of the Cloud Services Virtual IP Address (VIP). This public IP address can for example used by an IIS website running on a specific IaaS virtual machine (VM) which is part of that Cloud Service. You can work around this problem, as in many of these cases, by using Azure PowerShell. Below I will wake you through this process with an example.

Overview used Azure VMs:

clip_image002
1) First, we need to login and prepare the ARM environment. To do so run following PowerShell commands (change variables as needed):

clip_image004

clip_image006

2) Next we need to login to the ASM environment

clip_image008

3) As the next step we need to reserve the public IP Address

clip_image010

4) Next we need to de-associate the Reserverd IP address from the Cloud Service. Press Yes when asked

clip_image012

clip_image014

5) When you now check the list of reserved IP addresses, it will show the reserved IP address 40.68.191.13 as unassigned. The attribute InUse is set to False and the ServiceName and DeploymentName attributes are empty

clip_image016

6) Also check if the Reserved IP address is valid for migration

clip_image018

7) Next we need to prepare the Reserved IP address for migration

clip_image020

8) Now run the following PowerShell command to finalize the migration of the Reserved IP address

clip_image022

9) You can verify the availability of the migrated Public IP address by login in to the Azure portal. Under Public IP address, you should see the resource with the correct IP address

clip_image024

clip_image026

10) Now, you can move this resource to the correct resource group. When you do so, and your asked to Confirm the move, click Yes

clip_image028

clip_image030

clip_image032

11) Afterwards you can assign the public IP address to whichever resource you would like

clip_image034

clip_image036

That concludes this blog post. Hope it comes to your use.

Wim Matthyssen (@wmatthyssen)

Azure IaaS: Build a VM from a Bring your Own License (BYOL) image with Azure PowerShell

9:16 am in ARM, Azure, Azure Hybrid Use Benefit, BYOL, Cloud, IaaS, PowerShell by Wim Matthyssen

For all people who do not yet know, with the Azure Hybrid Use Benefit you can use your on-premises Windows Server licenses that includes Software Assurance for Windows Server (Standard and Datacenter Editions) virtual machines (VM) in Azure. More recently also Azure Hybrid Use Benefits for Windows Client which includes Windows 10 (only Enterprise customers with Windows 10 Enterprise E3/E5 per user or Windows VDA per user – User Subscription Licenses or Add-on User Subscription Licenses – are eligible) came in Preview.

By using your existing licenses, you only pay for the base compute rate (equal to the Linux rate for VMs) without the Windows licenses cost, which can save you up to 40 %.

You can download the Azure Hybrid Use Benefit datasheet here

clip_image002

These days it’s even simpler to deploy a new Azure server VM whit your own on premise license via the Windows Server BYOL images available in the Azure Marketplace. There are images available for the following Server Oss (*be aware that not all Azure Subscriptions can use the BYOL images):

  • Windows Server 2008 R2 SP1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016 (not available in all regions)

You can search for the Windows Server images by running following PowerShell command:

clip_image004

In the above screenshot, you can see that some Skus now contain the BYOL suffix.

You can search for the Windows Client images by running following PowerShell command:

clip_image006

To build a VM with from a BYOL image you can run following Azure PowerShell script (adjust all variables for your own use):

clip_image008

The script is also available on Microsoft TechNet

When the script is completed and the VM is build, you can log into the VM via remote desktop. Like you can see the VM is not registered and you’ll able to use your own Windows product key.

clip_image010

Hope this comes in handy!

Wim Matthyssen (@wmatthyssen)

How to connect an Azure ARM VNet to an ASM VNet using VNet Peering

4:25 pm in ARM, ASM, Azure, Azure virtual network, Cloud, DC, DNS, VNet peering by Wim Matthyssen

Hi all,

In this blog post I will show you how you can connect an Azure Resource Manager (ARM) virtual network (VNet) to a classic or Azure Service Manager (ASM) VNet using VNet Peering.

VNet Peering, which was made generally available (GA) on September 28th, is a mechanism that allows you to connect two VNets in the same region through the Azure backbone network as they were a single network. This means that you don’t need a VNet gateway anymore, like when you setup a VNet-to-VNet VPN connection. It will allow full connectivity between the entire address space of the peered VNets. So, for example when VNet peering is setup, all virtual machines in the peered VNets will be able to communicate with each other. If you’re interested you can read more about VNet Peering via following link: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

Before we start setting things up, first some things to keep in mind:

  • VNet Peering requires that both VNets are located the same Azure region
  • The VNets must be in the same Azure Subscription (only for ARM – ASM VNet Peering)
  • The IP address space of both VNets must not overlap
  • Using your peer’s VNet gateway (UseRemoteGateways and AllowGatewayTransit settings) is not supported when peering with an ASM VNet
  • There is a small charge for data transferred between VNets using VNet Peering (inbound and outbound data transfer $ 0,01 per GB)
  • To be clear, you can find below a drawing of my ARM – ASM VNet Peering setup

clip_image002

After all this is said and shown, we can start

1) First of all login to the Azure portal and sign in with your Azure account

2) Select Virtual Networks

clip_image004

3) Select your ARM VNet (in my case AZU-Vnet-ARM)

clip_image006

4) Click Peerings (like you can see there is one connected device AZU-APP-01)

clip_image008

5) Click Add

clip_image010

6) In the Add Peering blade, name your link (in my case LinkToVNetASM). Under Peer details select Classic. Choose the correct Subscription and the ASM Virtual Network you want to peer with. Leave Allow virtual network access Enabled, this will allow communication between the two virtual networks. Then click OK

clip_image011

7) After clicking OK the peering link will be created

clip_image012

8) When done, the two virtual networks are peered and you will see the PEERING STATUS between the two virtual networks is in a Connected state

clip_image014

9) Like you can see, both VMs can ping each other. Don’t forget to allow ping through the Windows Firewall

clip_image016

clip_image018

10) After adding AZU-DC-01 (10.0.1.36) as DNS server to the AZU-Vnet-ARM VNet, I was able to add AZU-APP-01 to the azuvlab.local domain which was created an AZU-DC-01

clip_image020

clip_image022

clip_image024

This concludes this blog post. If you have any questions don’t hesitate to contact me via twitter.

Wim Matthyssen (@wmatthyssen)