Azure Data Box Disks just went from preview to general availability and became available in more regions

Yesterday, Microsoft announced the general availability for Azure Data Box Disks.

For those who don’t know what this is, Azure Data Box Disks are basically a fast (SSD disk based), reliable and secure solution to do offline data transfer to Azure.

It’s been a while since Microsoft announced the preview program, and that was available only for the EU and US regions. General availability is for EU, US, Australia and Canada. As Microsoft promised, the service is expanding to more Azure data centers worldwide.

When compared to the Azure Import/Export service, using the Azure Data Box Disks is, in theory, a simpler process, since Microsoft will provide the disks and handle all the logistics.

We’ll have to wait and see where Microsoft will drive this service towards, since the expectation of some customers is to see it handle other things, besides just simple data transfer, such as initial seeding for Azure Backups.


Azure Tip: Use PowerShell to check all blob spaced used in a Storage Account

Just recently, I had the need to be able to know the exact volume of all blob container data, within a specific Azure Storage Account.

This was part of a migration project, which in this case meant that I needed to report that data amount multiple times per day. Data was constantly being copied to and deleted from that Storage account, and the same applies to Blob containers being created, filled with data and deleted afterwards. So my only constant was the Storage Account, and I needed to know, every 2 hours, what was the volume of blob container data in that account.

After a quick of research I found this outstanding Microsoft article on how to leverage the Azure PowerShell module (yes, PowerShell to save the day again!!) to calculate the size of a Blob Storage Container.

The only limitation with the script in the article above was that it’s calculating the size of a single blob container, and I needed the combined size of all blob containers in my Storage Account.

So I had to adapt that script to my scenario, and I turned it into the following script:

# Connect to Azure

# Static Values for Resource Group and Storage Account Names
$resourceGroup = "ChangeToYourResourceGroupName"
$storageAccountName = "changetoyourstorageaccountname"

# Get a reference to the storage account and the context
$storageAccount = Get-AzureRmStorageAccount `
-ResourceGroupName $resourceGroup `
-Name $storageAccountName
$ctx = $storageAccount.Context

# Get All Blob Containers
$AllContainers = Get-AzureStorageContainer -Context $ctx
$AllContainersCount = $AllContainers.Count
Write-Host "We found '$($AllContainersCount)' containers. Processing size for each one"

# Zero counters
$TotalLength = 0
$TotalContainers = 0

# Loop to go over each container and calculate size
Foreach ($Container in $AllContainers){
$TotalContainers = $TotalContainers + 1
Write-Host "Processing Container '$($TotalContainers)'/'$($AllContainersCount)'"
$listOfBLobs = Get-AzureStorageBlob -Container $Container.Name -Context $ctx

# zero out our total
$length = 0

# this loops through the list of blobs and retrieves the length for each blob and adds it to the total
$listOfBlobs | ForEach-Object {$length = $length + $_.Length}
$TotalLength = $TotalLength + $length
# end container loop

#Convert length to GB
$TotalLengthGB = $TotalLength /1024 /1024 /1024

# Result output
Write-Host "Total Length = " $TotallengthGB "GB"


The script above will provide you an output into the console of the total volume, in GB, that you have on a specific storage account.

To execute the script, follow the steps below:

  • Copy the entire code above to a notepad
  • Change the values of line 2 and 3, to the correct names of your Azure Resource group and your Azure Storage Account
  • Save the file as .ps1
  • Open a PowerShell window and execute the “script.ps1” file you just saved (see screenshot below)
  • Authenticate with your Azure username and password, when prompted


Execute the script as shown above.


When prompted, authenticate.


And this is how the end result should look like.

Before I end this blog post I’d just like to point out that this script was written in a very simplistic way, and to address an urgent need that I had. With a couple more hours of work, you can make this script even easier to use and add all sorts of different features to it, such as:

  • Error handling
  • remove the hard coded values and list for selection all available storage accounts and resource groups
  • change the output format (i.e to CSV) and list sizes per blob container
  • allow you to select between multiple Azure subscriptions under the same account

The above are just some ideas on how to improve the script. I haven’t done it because I had no need for it, but by all means please let me know if you want/need an improved version. This one works just fine, if all you want is the total volume of blob data in a specific storage account.

Happy New Year!!!

Azure Identity training, anyone?

With the New Year starting, I am looking at a training plan for 2019.

I don’t think that training is the only thing that makes you improve your skills, and at least in my opinion you should add to that as much real live consulting experience as you can, as well as make your training as much “hands on” as possible. Don’t just read or watch videos, build a lab and execute everything that you’re learning.

This blog post is to share with you what seems to be an excellent training resource in Azure Identity: Microsoft Azure Identity training in the platform.

With this training, as they state in their website, you’ll learn the following:

  • How to create and manage Azure Active Directory (AD) directories.
  • How to implement applications in Azure AD.
  • How to extend on-premises AD to Azure.
  • How to configure multi-factor authentication.

The prerequisites for this training are:

  • General understanding of cloud computing models.
  • General understanding of virtualization, networking and Active Directory.
  • Basic proficiency in PowerShell and command line interface scripting.

The above basically means that you should have some experience with Azure, virtualization and of course as this training is focused in Microsoft Identity Management, that means you need to clearly understand how Active Directory works. Finally, as in everything Azure related, PowerShell knowledge is a must! 🙂

All training that I did with has been great. The training is free, but if you choose to get a certificate at the end, you can pay 99USD, knowing you’d be helping the only nonprofit and open source learning platform.

Most of my posts are about real life scenarios, tips and tricks, etc, so I am sure I will be blogging a lot about Azure Identity in the near future.

Azure Resource Manager PowerShell: How to change between subscriptions

Today’s post is a very simple one. For those of you that like me, have multiple subscriptions on your Azure account and automate a lot of your Azure work via PowerShell, you might need to change between subscriptions, in the same PowerShell session, to execute multiple tasks.

This can be done with one of the two following cmdlets:

And here is where the confusion comes. What’s the difference between the two cmdlets and which one should you use?

Well the answer is the cmdlets do the exact same thing, and you should use the “Set-AzureRMContext” cmdlet, specially if you put it into scripts, since it seems to be the replacement for the “Select-AzureRMSubscription” cmdlet.

In fact, this is what you get when you do a “Get-Help Select-AzureRMContext”:


As you can see above all references point to the new cmdlet.

Now a quick note on how the cmdlet works.

To list all of your subscriptions:


To change the context to a different subscription:

Set-AzureRMContext -subscription <SubscriptionID or SubscriptionName>

I hope the above is helpful. Happy scripting!

Azure: “CurrentStorageAccountName is not accessible” error when creating a VM via the SDK

I just recently faced an error when doing an Azure lab, that I thought I should blog about, since the resolution is very simple.

Here’s what happened, I was creating a VM via the SDK using the Service Module (Classic – see note below) and the following cmdlet:

New-AzureQuickVM –Windows –ServiceName “AV-AutoSVC” –name “AV-AutoVM” –ImageName $image –Password $password -Location “East US” -InstanceSize “Basic_A0” -AdminUsername avargasadmin

Note: You can create virtual machines both with the service model (classic deployment) or with the Resource manager (new portal). Both methods are available via SDK but the way to connect is different. You use Add-AzureAccount to login to the service model and Add-AzureRMAccount to login to the resource manager. See differences here.

And I got the following error:


New-AzureQuickVM: CurrentStorageAccountName is not accessible. Ensure the current storage account is accessible and in the same location or affinity group as the cloud service.

Now after digging a little bit more in my Azure tenant and what might be the cause of the problem I confirmed that I did had the storage account, and even with the -Location parameter in the cmdlet above forcing it to be “East US” (where my storage account is) I was still getting the same error.

Then I decided to run a the following cmdlet:



I then realized that I have no valid storage account associated with my subscription, and the solution to my problem was to run:

Set-AzureSubscription –SubscriptionName <YourSubscriptionName> –CurrentStorageAccount <YourStorageAccountName>

If you don’t know your storage account name run:

Get-Azurestorageaccount |fl storageaccountname, location

Once you do this, re run your New-AzureQuickVM cmdlet (note: this error should happen also when you’re running the New-AzureVM cmdlet) and the error should be gone.


Office 365: Some quick notes on the end of support for Dirsync and Azure AD Sync

Earlier this week Microsoft announced the end of support for the legacy Microsoft Dirsync and Microsoft Azure AD Sync tools. Millions of customers out there use one of those two tools, or the new Microsoft Azure AD Connect, to sync their users, groups, passwords, etc, from their On-Premises Active Directory to the Azure AD.

After quite a few name changes, it looks like the Azure AD Connect major version is here to stay, and now it’s time to end support to the two older major versions, and make sure that all of them are updated and replaced with the AD Connect.

If you haven’t done it already, it’s time to read the Microsoft announcement, and to start planning that upgrade.

Now let’s take the key points of the Microsoft announcement:

  • In April 13th 2016 Microsoft announced the deprecation of both Dirsync and Azure AD Sync
  • The end of support for both versions of the sync tool was planned to be April 13th 2017. That date is now official with the announcement this week and in that day the official support to those tools is gone
  • Azure AD will stop accepting connections from both tools in December 31st 2017

The most relevant thing to take into account is that, either you upgrade those instances, or they will stop working by the end of this year.

Now that you are probably more than convinced to update your instance(s) for your customers or your infrastructure, let’s bullet point some thoughts to have into account when planning the upgrade:

  • Make sure you read the official Microsoft document to upgrade Dirsync to Azure AD Connect
  • Or make sure you read the official Microsoft document to upgrade Azure AD Sync to Azure AD Connect
  • You can only do in place upgrade from Azure AD Sync to AD Connect or from an old to a more recent version of AD Connect. In place upgrades from Dirsync are not supported
  • Microsoft describes the migration done with a parallel server, to replace the existing, as “Swing migration”
  • On a standard Dirsync or AD Sync instance, there’s nothing that you need to backup and restore in the new version. The new Azure AD Connect instance will do a fresh full sync after the installation. That full sync will bring all data from the local and the Azure AD. Replacing a Dirsync or an AD Sync instance should not require restoring data
  • The only exception to the above statement is when you have some type of filtering. Filtering can be done at the AD OU, Domain or attribute level. In those cases you need to make sure you replicate the filtering you have in place, into the new instance.
  • To learn more about Dirsync filtering click here.
  • To learn more about AD Sync and AD Connect filtering click here.
  • If you are not doing an in place upgrade, you need to be aware that the “downtime” on your sync instance has impact in creating new account and replicating changes to the existing ones (that includes password changes, if you have password sync enabled)

And that’s it. As simple as that. Start downloading the AD Connect version and it’s upgrade time! 🙂

Let me know if you have questions.

Set-AzureStaticVNetIP Error: The static address doesn’t belong to the address space defined by the role´s subnet

Quick blog post on a simple and logic error that you might get when you´re trying to set a static IP on your Microsoft Azure VM.


So as you can see above, when you try and run:

Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM |Set-AzureStaticVNetIP -IPAddress |Update-AzureVM

You get the error:

“Update-AzureVM : BadRequest : The static address doesn’t belong to the address space defined by the role’s subnets.”

The reason behind this error is simple: You are trying to set a static IP for your VM that does not belong to the subnet where the VM is. So let’s have a quick look on how to see which subnet does your VM belongs to. From the azure PowerShell run:

$MyVM = Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM

Get-AzureSubnet -VM $MyVM


The output will show you the Subnet of your VM.

You can also see the network where your VM is on by running:

Get-AzureVM |fl Name, VirtualNetworkName


Now that you know what network and subnet your VM is on, you can go to the Azure Portal > Networks, and on the Configure tab of the network you can see the range of IP addresses from the subnet of your VM:


In my case the VM is on the subnet-2, with a range of Ip’s of and i was trying to set up an IP address on the range.

Let’s try with a valid IP now on the network:


No error, job done, and as simple as it gets! 🙂

Microsoft Azure Tip: How to assign a static IP address to your Azure VM

This blog post will quickly show you how you can assign a static IP address to one of yours Microsoft Azure Virtual Machines, using the Microsoft Azure Powershell.

Assuming that you have already created at least one virtual machine, on your Azure subscription, the first thing you need to know and do is, how to install and configure the Azure Powershell.

On the article from the above link, you can follow the instructions to install the Microsoft Azure Powershell and to connect it to your Azure subscription.

Now let’s login to the Microsoft Azure Management Portal, and start by looking at the Virtual Networks.


I created a virtual network on my subscription, named “vlan192”, and as you can see the virtual machine “DC01” got the IP address assigned, which is part of a sub. Now I will change that IP address to one of my choosing.


Above you can see the virtual network in more detail. Before assigning a static IP address to your virtual machine, make sure the address you choose is within the usable address range of one of the subnets of your virtual network. My virtual network has two subnets.

One other thing that you need to take into account, is that when you create the Vitual Machine, you need to make sure that you assign the correct virtual network and subnet to it, as shown below:


You can always go to the Dashboard of the virtual network, and make sure that the Virtual Machine you created is listed there, and what subnet is the virtual machine using.

We can now connect to the Microsoft Azure Powershell and set the static IP. Let’s start by running the following cmdlet to see the details of the existing virtual machines:


The cmdlet above will give you the servicename and the virtual machine name that you need to run the cmdlet that sets the static IP:

Get-AzureVM -ServiceName <ServiceName> -Name <VMName>  | Set-AzureStaticVNetIP -IPAddress <StaticIP> | Update-AzureVM

Below you can see the output of the cmdlet.


And finally if you go to the properties of the virtual machine, on the Azure Management Portal, you can see that the static IP is set.



You need to be aware is that the IP above is assigned to the specific VM. A reservation is made and therefore that will be the IP of the virtual machine as long as the reservation is kept. This does not change the network properties at the OS level. It doesn´t set the static IP there. You should now login to the virtual machine and set the static IP to match the reservation, as you are now sure that it won’t cause any IP address conflict.