I've used Azure cli v2 to delete a resource group.
All resources get deleted except a single storage account.
There are no other resources in the subscription, no containers in the storage account, yet I get the "in use" error when I try to delete the storage account.
(there are 2 storage accounts now because I've managed to create this situation twice now - neither is deletable)
Steps take so far:
I've confirmed there are no disks or images assigned to any VMs via the classic console, the arm console, and the az cli.
I've deleted VHDs I found in the storage account, then retried the storage account delete but get same in use error.
I've tried to delete via the cli as well as web console (both arm and classic)
According to the error message, you can use PowerShell to list all the VHDs in the storage account, here is the script:
Login-AzureRmAccount
$RGName = "jason"
$SAName = "jasondisks690"
$ConName = "vhds"
$TempObj = New-Object -TypeName PSCustomObject
$TempObj |Add-Member -Name BlobName -MemberType NoteProperty -Value $null
$TempObj |Add-Member -Name LeaseState -MemberType NoteProperty -Value $null
$Keylist = Get-AzureRmStorageAccountKey -ResourceGroupName $RGName -StorageAccountName $SAName
$Key = $Keylist[0].Value
$Ctx = New-AzureStorageContext -StorageAccountName $SAName -StorageAccountKey $Key
$List = Get-AzureStorageBlob -Blob *.vhd -Container $ConName -Context $Ctx
$List | ForEach-Object { $TempObj.BlobName = $_.Name; $TempObj.LeaseState = $_.ICloudBlob.Properties.LeaseState; $TempObj }
replace the $RGName $SAName $ConName with your name.
Also, we can via new portal to check the storage account, and delete all container.
UPdate:
Here is a workaround:
1. creating a new VM in the same Resource Group as the problematic Storage Account. 2. Added the drive to the same Resource Group, same region, etc. 3. After creation I deleted out the new VM, then deleted out the VHD container for the VM in the problematic Storage Account. 4. After this I was able to remove the problematic Storage Account.
Related
I'm trying to create a runbook in Azure that accesses a blob storage and list the contents. But I keep getting the following error:
The remote server returned an error: (403) Forbidden. HTTP Status Code: 403 - HTTP Error Message: This request is not authorized to perform this operation using this permission.
I checked the following:
Azure Portal -> Storage Account -> Networking -> Check Allow Access From (All Networks / Selected Networks)
It is set to all networks.
I checked the SAS. It's correct.
On the storage account and the container I set the Access Control to Storage Blob Data Reader and Sotrage Blob Data Owner to Managed Identity\Automation Account.
i created an Access Policy and set its rights to rdl, but I don't know how to call it from within my Powershell statement. I don't know whether it makes any difference.
Who can help me? I've about read all the articles on Internet but can't find the answer.
It's the statement Get-AzureStorageBlob that fails.
This is the code in the runbook:
$storage = "opslag" #name of storage account
$blobcontainer = "contener" #name of container
$sas = "****"
Write-Output $storage
Write-Output $container
$context = New-AzureStorageContext -StorageAccountName $storage -
SasToken $sas
Write-Output $context
$blobs = Get-AzureStorageBlob -Container $blobcontainer -Context
$context
To test this in our local environment, we have created a storage account, automation account with PowerShell runbook
We have enabled Managed identity for the automation account, given the permissions Storage blob data Reader, Storage Blob Data Owner for the same managed identity.
In the storage account, we have created an access policy with read, delete, list permissions to access the blob contents from PowerShell statements.
Here is the PowerShell Script that we have run in the Automation account Runbook:
We have used the same managed identity to authenticate to our azure account in the automation account.
Disable-AzContextAutosave -Scope Process # Ensures you do not inherit an AzContext in your runbook
$AzureContext = (Connect-AzAccount -Identity).context # Connect to Azure with system-assigned managed identity
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext # set and store context
Import-module -name Az.Storage
$storage = "<strgName>" #name of storage account
$blobcontainer = "<containerName>" #name of container
$sas = "<SAStoken>" # Generated SAS token for the container with allowing HTTP & HTTPS protocol.
Write-Output $storage
Write-Output $container
$context = New-AzStorageContext -StorageAccountName $storage -SasToken $sas
Write-Output $context
$blobs = Get-AzStorageBlob -Container $blobcontainer -Context $context
Write-Output $blobs
Here is the sample output for reference:
Regardless of the type of storage accounts in Azure. Is there any way to create SAS token in Powershell or portal(doesn't seem like) that has exclusive access to a blob and not rest of blobs in the same storage account
Seems below command is available but maybe for different storage account type and not necessary for a blob
New-AzStorageBlobSASToken;
I did create SAS token with below PowerShell script but this token is for the whole blob service
$SA = Get-AzStorageAccount | Select-Object StorageAccountName,ResourceGroupName,Location,SkuName,CreationTime | Out-GridView -PassThru
$key = Get-AzStorageAccountKey -ResourceGroupName $SA.ResourceGroupName -Name $SA.StorageAccountName
$context = New-AzStorageContext -StorageAccountName $SA.StorageAccountName -StorageAccountKey $key.value[0]
$sas = New-AzStorageAccountSASToken -Service Blob, File, Table, Queue -ResourceType Service, Container, Object -Permission "racwdlup" -Context $context
Write-Output $sas
New-AzStorageBlobSASToken does exactly that. It creates a SAS token for one specific blob (think of blob=file in this case)
https://learn.microsoft.com/en-us/powershell/module/az.storage/new-azstorageblobsastoken?view=azps-2.7.0#examples
we want to move all of our Linux VMs from a subscription in one region to a subscription in another region. I found a few threads that this isn't possible at the moment, but there are workarounds. Unfortunately I'm stuck.
Since I want to move the VMs as they are (the subscription where the VMs are currently running will be terminated) I guess I don't have to deprovision the images? Do I have to generalize them for the transfer?
Whats the best way to get them to the other subscription? I played with the AzCopy command and actually was able to copy files from a container from the first subscription to a container of the other one in another region.
Then I thought I could copy the vhds of the VMs but couldn't find them in the blob containers of our storage accounts.
After that, I created a snapshot, but couldn't find it in the blob containers as well. So I also couldn't copy them with AzCopy.
Thank you for every help, kopi
As with everything, it depends how you've set your VM's disks up. The two options are managed and unmanaged disks.
If your disks are managed, they won't be in a storage account and that's probably why you can't find them, however you should check in the Disks blade of the VM to be certain. An unmanaged disk will show a reference to the VHD URI when you look closer inside the disks blade of the VM resource and will include "unmanaged" in brackets as per this screenshot.
If your disk is managed, and you want to copy it to a storage account as a VHD, these few lines will get you started. Obviously this is PowerShell. You will need to be running a recent version (WMF 5.1 preferably) of PowerShell and install the latest AzureRM modules (Install-Module AzureRm -Scope CurrentUser).
$token = Grant-AzureRmDiskAccess -ResourceGroupName sourceresourcegroupname -DiskName sourcemanageddiskname -DurationInSecond 3600 -Access Read
$destContext = New-AzureStorageContext –StorageAccountName destinationstorageaccount -StorageAccountKey 'destinationstorageaccountkey'
Start-AzureStorageBlobCopy -AbsoluteUri $token.AccessSAS -DestContainer 'vhds' -DestContext $destContext -DestBlob 'destinationblobname.vhd'
If on the other hand you have unmanaged disks, the process is a little more complex. Again, the following is PowerShell. You need the source VHD URI (see the screenshot above) and then to provide the destination blob information.
Select-AzureRmSubscription 'SourceSubscription'
### Source VHD - authenticated container ###
$srcUri = "https://sourcestorageaccount.blob.core.windows.net/vhds/nameoffile.vhd"
### Source Storage Account ###
$srcStorageAccount = "sourcestorageaccount"
$srcStorageKey = "sourcestorageaccountkey=="
### Create the source storage account context ###
$srcContext = New-AzureStorageContext –StorageAccountName $srcStorageAccount `
-StorageAccountKey $srcStorageKey
# Target Storage Account
Select-AzureRmSubscription 'DestinationSubscription'
### Target Storage Account ###
$destStorageAccount = "destinationstorageaccount"
$destStorageKey = "destinationstorageaccountkey=="
### Create the destination storage account context ###
$destContext = New-AzureStorageContext –StorageAccountName $destStorageAccount `
-StorageAccountKey $destStorageKey
### Destination Container Name ###
$containerName = "copiedvhds"
### Create the container on the destination ###
New-AzureStorageContainer -Name $containerName -Context $destContext
### Start the asynchronous copy - specify the source authentication with -SrcContext ###
$blob1 = Start-AzureStorageBlobCopy -srcUri $srcUri `
-SrcContext $srcContext `
-DestContainer $containerName `
-DestBlob "destinationblob.vhd" `
-DestContext $destContext
### Loop until complete ###
While($status.Status -eq "Pending"){
$status = $blob1 | Get-AzureStorageBlobCopyState
Start-Sleep 300
### Print out status ###
$status
}
One thing I will mention is that if you are running managed disks, there are options in the portal to move the disk to another subscription. If you wish, come back with your current disk type (managed or unmanaged) and let me know what the target type you expect/want it to be and we can work from there.
On the assumption that you created a copy of a VHD blob in a new storage account in the target subscription (ie. You didn't create a snapshot of a managed disk), you can "wrap" a VM container around the disk using the following PowerShell. The important line is the Set-AzureRmVMOSDisk where we use the Attach option to simply create the config and plug the disk in.
# Name the new server
$ServerName = 'MYSERVER'
# Provide the URI of the disk to be attached as the OS disk.
$LocationOfVHD = "https://destinationstorageaccount.blob.core.windows.net/copiedvhds/destinationblob.vhd"
# Create a NIC and get the target VNET and subnet references.
$nicName = "$ServerName-nic"
# Set the private IP Address of the NIC
$PrivateIPAddress = '10.203.99.4'
# Set the DNS server for the NIC
$DNSServerAddress = '10.203.99.4'
# Destination resource group
$DestinationResourceGroupName = 'RG-DESTINATION'
# Location where the resources are to be built
$LocationOfResources = 'UK West'
# Select the appropriate subscription
Select-AzureRmSubscription 'DestinationSubscription'
# Create a VM machine configuration
$VM = New-AzureRmVMConfig -VMSize 'Standard_DS2_v2' -VMName $ServerName
# Set the VM OS Disk value to the URI where the disk was restored/copied and attach it. Set the OS type and caching as desired
Set-AzureRmVMOSDisk -VM $VM -Name "$ServerName-OS" -VhdUri $LocationOfVHD -CreateOption "Attach" -Windows -Caching ReadWrite
# Get the reference to the VNET in which the NIC will be bound.
$vnet = Get-AzureRmVirtualNetwork -Name "TargetAzureNetwork" -ResourceGroupName 'TARGETVIRTUALNETWORK'
# Get the reference to the Subnet ID in which the NIC will be bound.
$Subnet = $vnet.Subnets | Where-Object {$_.Name -eq 'TARGETSUBNET'} | Select-Object 'Id'
# Get the ID of the NSG which will be bound to the NIC - if you want.
$NSG = Get-AzureRmNetworkSecurityGroup -ResourceGroupName $DestinationResourceGroupName -Name 'NSG-DESTINATIONVM'
# Create the NIC with the VNET/subnet reference
# You could also define here the backend load balanced pool etc that this NIC belongs to.
$NIC = New-AzureRmNetworkInterface `
-Name $nicName `
-ResourceGroupName $DestinationResourceGroupName `
-Location $LocationOfResources `
-SubnetId $Subnet.Id `
-NetworkSecurityGroupId $NSG.Id `
-PrivateIpAddress $PrivateIPAddress `
-DnsServer $DNSServerAddress
# Add the newly created NIC to the VM definition.
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $NIC.Id
# Create the VM
New-AzureRmVM -ResourceGroupName $DestinationResourceGroupName -Location $LocationOfResources -VM $VM
Hopefully that's a decent starter for you but come back if you need more. If you're new to PowerShell though, I apologise but to do what you're asking, you either need PowerShell or the Azure CLI.
UPDATE (now I know these are managed disks):
With a little more clarity, here's your process.
I personally would do most if not all of this in PowerShell (Azure modules) but sensing you’re new to it, I’ll navigate you through the portal method. Unfortunately, a little PowerShell will be needed so prepare yourself.
Create a target storage account in the destination subscription –
you need to use an intermediate storage account as part of this
process. You also need a Virtual Network of course.
Shut down your source VM.
Navigate to the Disks blade and select one of the disks.
Click Create Snapshot. Repeat for any other disks attached to the VM and then of course all other VMs. Once you’ve got your snapshots, you can turn the VMs back on.
One could argue that you don’t have to create snapshots if you’re happy for the VMs to remain off while you copy the source VHD using an access URL like you’d get if you chose Export > Generate URL instead of creating a snapshot. We’re creating snapshot since you might actually want your VMs to be running again quickly.
For each snapshot that you created, you’ll need to copy it as a blob to a new target account.
Open each snapshot and click Export. Increase the valid time to 86400 seconds (one day), then click Generate URL.
Make sure you copy the URL that’s generated and don’t lose it.
Here comes the PowerShell which we use to download the generated URL in to a blob in our destination subscription and storage account. The download process takes a while per disk so be prepared! Remember you need to do this for every snapshot of every disk, altering names and possibly storage accounts for each VM as required. (this is the reason why I would choose to use PowerShell).
Source VHD - authenticated container ###
$srcUri = "https://md-f0p4tdq5fjpc.blob.core.windows.net/txwptxxxqvct/abcd?sv=2017-04-17&sr=b&si=cce17550-75f7-429c-bf08-31d0ae2da552&sig=oI%2BNOmQ4F75H8AlSwm7rJb%2Frm2Jhl9kfNZ7Jt2cUJpY%3D"
# Target Storage Account
Select-AzureRmSubscription 'DestinationSubscription'
### Target Storage Account ###
$destStorageAccount = "destinationstorageaccount"
$destStorageKey = "IkEvDdWTvTxN7v45VgAcvyEpZB9rGyYwyZhxvhG6eQaPIB15MQOa0vkvsHxMDpmUIJqq42UGiU8ji5Lqt39rAg=="
### Create the destination storage account context ###
$destContext = New-AzureStorageContext –StorageAccountName $destStorageAccount `
-StorageAccountKey $destStorageKey
### Destination Container Name ###
$containerName = "vhds"
### Create the container on the destination ###
New-AzureStorageContainer -Name $containerName -Context $destContext
### Start the asynchronous copy
$blob1 = Start-AzureStorageBlobCopy -AbsoluteUri $srcUri `
-DestContainer $containerName `
-DestBlob "destinationblob.vhd" `
-DestContext $destContext
$status = $blob1 | Get-AzureStorageBlobCopyState
### Loop until complete ###
While($status.Status -eq "Pending"){
$status = $blob1 | Get-AzureStorageBlobCopyState
Start-Sleep 300
### Print out status ###
$status
}
Once the blob copy is complete, we will need to wrap a VM around our disk (or disks!). As part of this process though, we will Import the VHD that is now in our target storage account in to a managed disk and attach it to the VM. More PowerShell unfortunately but this looks very similar to the PowerShell I’ve shared earlier. There are comments so you know what’s going on.
# Name the new server
$ServerName = 'DESTINATIONSERVERNAME'
# Provide the URI of the disk to be attached as the OS disk.
$LocationOfOSVHD = "https://destinationstorage.blob.core.windows.net/vhds/destinationblob.vhd"
$LocationOfDataDisk1 = "https://lrdestinationstorage.blob.core.windows.net/vhds/destinationblob1.vhd"
# Create a NIC and get the target VNET and subnet references.
$nicName = "$ServerName-nic"
# Set the private IP Address of the NIC
$PrivateIPAddress = '10.0.0.4'
# Set the DNS server for the NIC
$DNSServerAddress = '8.8.8.8'
# Destination resource group
$DestinationResourceGroupName = 'RG-DESTINATION'
# Location where the resources are to be built
$LocationOfResources = 'West Europe'
# Select the appropriate subscription
Select-AzureRmSubscription 'DestinationSubscription'
# Create a VM machine configuration
$VM = New-AzureRmVMConfig -VMSize 'Standard_DS2_v2' -VMName $ServerName
# Create a managed disk configuration and import the source VHD
$OSDisk = New-AzureRmDiskConfig -AccountType StandardLRS -Location $LocationOfResources -CreateOption Import -SourceUri $LocationOfOSVHD
# Create the managed disk using the configuration defined above.
$Disk1 = New-AzureRmDisk -DiskName 'OS-DISK' -Disk $OSDisk -ResourceGroupName $DestinationResourceGroupName
# Set the VM’s OS Disk to be the managed disk.
Set-AzureRmVMOSDisk -VM $vm -ManagedDiskId $Disk1.Id -StorageAccountType StandardLRS -DiskSizeInGB 80 -CreateOption Attach -Windows -Caching ReadWrite
# Repeat ourselves for any data disks that must also be attached to the VM in the destination.
# Increase LUN numbering and changing names etc as required.
$DataDisk = New-AzureRmDiskConfig -AccountType StandardLRS -Location $LocationOfResources -CreateOption Import -SourceUri $LocationOfDataDisk1
$Disk2 = New-AzureRmDisk -DiskName 'DATA-1' -Disk $DataDisk -ResourceGroupName $DestinationResourceGroupName
Add-AzureRmVMDataDisk -ManagedDiskId $Disk2.Id -VM $vm -CreateOption Attach -DiskSizeInGB 20 -Caching ReadWrite -StorageAccountType StandardLRS -Name 'DATA-1' -Lun 0
# Get the reference to the VNET in which the NIC will be bound. Might not be in the resource group you’re migrating to so this is left manual.
$vnet = Get-AzureRmVirtualNetwork -Name "DestinationAzureNetwork" -ResourceGroupName 'RG-DESTINATION'
# Get the reference to the Subnet ID in which the NIC will be bound. Replace 'default' with the name of the target subnet
$Subnet = $vnet.Subnets | Where-Object {$_.Name -eq 'default'} | Select-Object 'Id'
# Create the NIC with the VNET/subnet reference
# You could also define here the backend load balanced pool etc that this NIC belongs to.
$NIC = New-AzureRmNetworkInterface `
-Name $nicName `
-ResourceGroupName $DestinationResourceGroupName `
-Location $LocationOfResources `
-SubnetId $Subnet.Id `
-PrivateIpAddress $PrivateIPAddress `
-DnsServer $DNSServerAddress
# Add the newly created NIC to the VM definition.
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $NIC.Id
# Create the VM
New-AzureRmVM -ResourceGroupName $DestinationResourceGroupName -Location $LocationOfResources -VM $VM
And that should do what you're after.
There's some considerations obviously and you'll need to edit the script each time you're doing a copy or re-creating the VM. This is not ideal but I've tried to take in to consideration your PowerShell familiarity. Otherwise this whole thing would have been PowerShell.
How do I create a SAS url for my entire cloud storage account?
I noticed the azure powershell cmdlets have a lot of ways to create SAS urls for specific resources (e.g. blob, queue, etc..), but I would like to create one SAS for all of them with powershell
I assume that you want to use Azure storage account SAS. More details please refer to the New-AzureStorageAccountSASToken
New-AzureStorageAccountSASToken
-Service <SharedAccessAccountServices>
-ResourceType <SharedAccessAccountResourceTypes>
[-Permission <String>]
[-Protocol <SharedAccessProtocol>]
[-IPAddressOrRange <String>]
[-StartTime <DateTime>]
[-ExpiryTime <DateTime>]
[-Context <IStorageContext>]
[<CommonParameters>]
example : New-AzureStorageAccountSASToken -Service Blob,File,Table,Queue -ResourceType Service,Container,Object -Permission "racwdlup" -Context $ctx
Edit:
I have already tried this API. It does not allow you to specify which Azure StorageAccount to generate the SAS for.
I test with resource mangment storage account, it works correctly on my side. Details please refer to the screenshot.
$resourceGroup = "Resource group"
$storageAccountName = "account name "
Login-AzureRmAccount
$storageAccount = Get-AzureRmStorageAccount -ResourceGroupName $resourceGroup -Name $storageAccountName
$ctx = $storageAccount.Context
$accountSAS = New-AzureStorageAccountSASToken -Service Blob,File,Table,Queue -ResourceType Service,Container,Object -Permission "racwdlup" -Context $ctx
I was playing with Windows Azure durable virtual machines. In the end, I deleted the virtual machine (successfully) and tried to delete the associated storage account.
The request to delete the storage account fails.
On the Preview Portal (manage.windowsazure.com) when I delete the storage account I get this error:
Failed to delete Storage account 'portalvhdscwtwycpsxxxxx'
Details:
Storage account portalvhdscwtwycpsxxxxx has 1 container(s) which have an active image and/or disk artifacts. Ensure those artifacts are removed from the image repository before deleting this storage account.
On the previous portal (windows.azure.com) I get this error:
Submit Failed
Storage account portalvhdscwtwycpsxxxxx has 1 container(s) which have an active image and/or disk artifacts. Ensure those artifacts are removed from the image repository before deleting this storage account.
Trying to delete the blob itself (a 30GB VHD) on Azure Storage Explorer I get this error:
There is currently a lease on the blob and no lease ID was specified in the request.
So my assessment is that this blob is leased (by the previous, now deleted virtual machine) and I can't delete it unless I can get this lease ID.
The question is: how can I delete this blob and, consequently, the storage account?
The key to the solution is the message that the container has an active disk artifact and the advice to remove it from the repository.
The procedure to remove the disk image from the blob repository is:
Go to the Windows Azure Management Portal.
Click on Virtual Machines.
Click on Disks.
Click on the disk.
Click on Delete Disk.
After that, the storage account can be deleted.
Notes:
This applies even if you've already deleted all of your Virtual Machines and it shows 0; there still will be artifacts under the disks tab.
Disks are detached from a deleted VM asynchronously, it may take a few minutes after the VM is deleted for this field to clear up.
See also: Unable to delete VHD, “There is currently a lease on the blob…”
Unfortunately, Fernando's answer didn't work for me, since the storage was "orphan", as I deleted its VM before deleting the storage. I couldn't find a way to do it from the portal so I've installed azure-cli, and after authentication ran the following commands:
azure storage account delete <my-account>
This fails, and the error message contains the name of culprit, e.g.:
error: Storage account <my-account> has some active image(s) and/or disk(s), e.g. <my-image>. Ensure these image(s) and/or disk(s) are removed before deleting this storage
Then I deleted the offending image
azure vm disk delete <my-image>
And tried again to delete the storage, this time successfully.
azure storage account delete <my-account>
Unfortunately there is the case where the VM was deleted but Disks shows the VM attached to the blob (a 30GB VHD) precluding the deletion. Also there is the case of using the Azure Storage Explorer you find an orfan but leased VHD blob that can't be deleted and there is no reference on the Preview Portal.
Go to virtual machines, then click on discs. Mark the disc and choose delete disc at the bottom. You can now choose if you want to keep or delete the corresponding vhd.
It is important first to delete the disc via virtual machines not to delete via storage.
You can use Iaas Management Studio : break the lease, delete the blob, then remove the orphaned image.
In my case, storage could not be deleted because of vmimages.
Use power shell command
get-azurevmimage | Where-Object -Property Category -in -Value "user"
to list all images
To delete ALL YOU IMAGES use the following script:
get-azurevmimage | Where-Object -Property Category -in -Value "user" |
foreach {
echo "remove $($_.ImageName)"
Remove-AzureVMImage –ImageName $($_.ImageName)
}
As F.M. has already stated; there is a scenario where when deleting a VM the disk still shows as attached to the VM even though the VM has been deleted.
For me this happened because I had a set a spending limit. When the spending limit is hit, your services are disabled. Any VPN gateways you have created and VMs will be deleted. Then to top it off the disks attached to the deleted VMs still think they are attached :(
I have found this blog that explains the issue and shows how to use powershell to resolve.
Hope this helps other users.
Sometimes we via the new portal to delete azure storage account, but we can’t delete it and get this error:” Failed to delete storage account 'jason1disks796'. Error: The storage account cannot be deleted due to its artifacts being in use. “
We can use PowerShell to list all the VHD blobs of the storage account(ARM module):
PS > Login-AzureRmAccount
PS > $RGName = "jason1"
PS > $SAName = "jason1disks796"
PS > $ConName = "vhds"
PS > $TempObj = New-Object -TypeName PSCustomObject
PS > $TempObj |Add-Member -Name BlobName -MemberType NoteProperty -Value $null
PS > $TempObj |Add-Member -Name LeaseState -MemberType NoteProperty -Value $null
PS > $Keylist = Get-AzureRmStorageAccountKey -ResourceGroupName $RGName -StorageAccountName $SAName
PS > $Key = $Keylist[0].Value
PS > $Ctx = New-AzureStorageContext -StorageAccountName $SAName -StorageAccountKey $Key
PS > Get-AzureStorageContainer -Context $ctx
CloudBlobContainer : Microsoft.WindowsAzure.Storage.Blob.CloudBlobContainer
Permission : Microsoft.WindowsAzure.Storage.Blob.BlobContainerPermissions
PublicAccess : Off
LastModified : 1/19/2017 1:27:21 AM +00:00
ContinuationToken :
Context : Microsoft.WindowsAzure.Commands.Common.Storage.AzureStorageContext
Name : vhds
PS > $List = Get-AzureStorageBlob -Blob *.vhd -Container $ConName -Context $Ctx
PS > $List | ForEach-Object { $TempObj.BlobName = $_.Name; $TempObj.LeaseState = $_.ICloudBlob.Properties.LeaseState; $TempObj }
BlobName LeaseState
-------- ----------
SQL20170119092405.vhd Leased
PS > Get-AzureStorageBlob -Blob * -Container $con -Context $ctx | Remove-AzureStorageBlob
PS > Remove-AzureRmStorageAccount -ResourceGroupName $RGname -Name $SAName
If your storage account is in the ASM module, you can use this script to remove storage account:
Add-AzureAccount
$SAName = "jason1161"
$ConName = "vhds"
$TempObj = New-Object -TypeName PSCustomObject
$TempObj |Add-Member -Name BlobName -MemberType NoteProperty -Value $null
$TempObj |Add-Member -Name LeaseState -MemberType NoteProperty -Value $null
$Keylist = Get-AzureStorageKey -StorageAccountName $SAName
$Key = $Keylist.primary
$Ctx = New-AzureStorageContext -StorageAccountName $SAName -StorageAccountKey $Key
$List = Get-AzureStorageBlob -Blob *.vhd -Container $ConName -Context $Ctx
$List | ForEach-Object { $TempObj.BlobName = $_.Name; $TempObj.LeaseState = $_.ICloudBlob.Properties.LeaseState; $TempObj }
PS > Get-AzureStorageBlob -Blob * -Container $con -Context $ctx | Remove-AzureStorageBlob
PS > Remove-AzureStorageAccount -Name $SAName
Besides, there is another scenario, there is no container or blob in this storage account (an empty storage account, we can’t find blob or container in this storage account via PowerShell or portal), when we use portal to delete the storage account, and the error message” Failed to delete storage account 'jason1disks796'. Error: The storage account cannot be deleted due to its artifacts being in use”. In this scenario we can create a new VM and specify the storage account to the problematic Storage Account, then delete it again.
Do check before deleting your storage account; there must be the associated virtual machine(s), Disks and Images for each storage account you created. Go to Azure portal
Select Virtual Machines tab on left pane
Click on Instances Images and Disks
Note that, Individual Virtual machines has its attached disks which show on Disks area.Before deleting a Virtual machine, delete the associated disks first and delete the virtual machine has the disk second.Then delete the storage account last. Also look out for Network in the same left-hand side pane if any associated with the account you want to delete.
In the new updated Azure portal, many of the above-stated config pages are changed. You can see Images and Disks options in "All resources" pane. In the newer version of an Azure portal, you can easily identify VMs its associated Disks and its Storage account clearly on its adjacent vertical panes all in one page with different icon images.
For those who rely on GUI to manage Azure and have no idea to use PowerShell or do the other answers, you can now delete the stuck storage account by checking "Delete unattached images" when trying to delete the storage.
It will automatically delete the storage without much hassle.