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.