Azure ARM Reserved Public Ip Addresses via Powershell

I’ve had the situation where the full allocation of IP addresses are needed up front for firewall configuration. This isn’t so bad when you only need a few, but if you’re going for your full allocation of 20 (or more if you’ve spoken to Microsoft Support) then it can get a little tedious using the Azure Portal UI.

The typical output from this should be something like;

My_IPBag_1 13.79.152.42 Succeeded
My_IPBag_2 13.79.159.10 Succeeded
My_IPBag_3 52.169.176.221 Succeeded
My_IPBag_4 13.79.156.94 Succeeded
My_IPBag_5 13.79.157.129 Succeeded
My_IPBag_6 13.79.153.147 Succeeded
My_IPBag_7 13.79.157.117 Succeeded
My_IPBag_8 13.79.153.183 Succeeded
My_IPBag_9 13.79.154.248 Succeeded
My_IPBag_10 13.79.157.10 Succeeded
My_IPBag_11 13.79.155.174 Succeeded

Note that the assigned IP addresses are not in a continuous range 🙂

If you do try to obtain more than 20 Public IP Addresses in your subscription then you’ll get this friendly error message.

New-AzureRmPublicIpAddress : Cannot create more than 20 public IP addresses with static allocation method for this subscription in this region.

Azure AD b2c error – could not load file or assembly ‘microsoft.identitymodel.protocol.extensions’

Following the Azure B2C Dev Quickstarts resulted in a build failure…

Could not load file or assembly ‘Microsoft.IdentityModel.Protocol.Extensions’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The quick fix is to update the Nuget package reference for the Protocol Extensions from version 1.0.0.0 to 1.0.2.33 using the Visual Studio Nuget package manager.

Subsequently the build then fails with this error;

The following errors occurred while attempting to load the app.
– No assembly found containing an OwinStartupAttribute.
– No assembly found containing a Startup or [AssemblyName].Startup class.
To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of “false” in your web.config.
To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config.

The fix for this one is to check your Startup.cs file for the OWIN assembly declaration.

These few changes should then result in a successful build.

Estimating your annual Azure bill

Following on from my last post when i was tinkering with the Azure EA Billing API…

If you have an Azure Enterprise Agreement, you might want to get a regular idea of where you usage (and money) is heading.

I got the idea from MyFitnessPal, which is a popular nutrition app.  At the end of every day, when you’ve logged your food and told it that you’re finished eating for the day it tells you that; “If every day was like today, then in 5 weeks you’d weigh 160lb’s” (Or something similar).

With utility billing, your usage could fluctuate wildly from day to day so it’s probably best not to take the single estimate without context from other metrics and information… But it’s fun to see what the bill would end up being.

Rather than just providing a straight powershell script, i’ve created a workflow that runs in the Azure Automation platform and submitted it to the public runbook gallery.

“Uses the Microsoft Azure Enterprise Agreement API to estimate your annual Microsoft Azure bill based on the last days usage.

The default Azure EA account is the sample account id and accesskey just so you can see it working before plugging your own details in. You should use the Microsoft Azure Enterprise portal to request your own accesskey.

I recommend adding the script to a daily schedule.

This script requires a credential asset for the your SMTP server in order to send the email.”

Here’s the (v1.0) version of the powershell script;

Using the Azure Billing API with Powershell

Once you’ve got an Enterprise Agreement with Microsoft Azure, you’ll probably want to know how much you’re spending.

As with everything Azure, you’re better off forgetting the UI and using Powershell.

Unfortunately, the billing API doesn’t return detailed information in a Json or xml format – it is a long string delimited by commas and linebreaks.

Before we can do anything with the detailed data we get from the API we need to clean it up into a powershell object.  Once we have a usable object to work with then we can start playing with the billing data.

In the example below, I’ve used the sample data account (Enrollment #100), just plug in your own enrollment number and the access key from the Azure Enterprise Site and you’ll be away.
For full documentation on the EA API, you can find the API guide here