We wanted to delete a resource group that contained a VM with IP and storage account etc.
Everything got deleted except the storage account because of a vhd which says it still has a lease. I can't break the lease because of the following error message:
Failed to break lease on 1 out of 1 blob(s):
VM2X-20170518-074152.vhd: This blob is being used by the system.
Is there a way to break the lease, delete the blob with the lease active, or find out where it is leased to?
Additional Info:
On the vhd on the "Edit blob" tab, I get the following message:
File size of '137.44GB' exceeds max supported file size of '2.1MB.'
This sounds like a familiar problem with classic storage accounts, if it's the problem I think it is you will need to delete image using Powershell.
Set Storage account
$storageAccountName = "your storage account"
Check OS Disk image
Get-AzureVmImage | Where-Object { $_.OSDiskConfiguration.MediaLink -ne $null -and $_.OSDiskConfiguration.MediaLink.Host.Contains($storageAccountName)`
} | Select-Object -Property ImageName, ImageLabel
Check Data Disk image
Get-AzureVmImage | Where-Object {$_.DataDiskConfigurations -ne $null `
-and ($_.DataDiskConfigurations | Where-Object {$_.MediaLink -ne $null -and $_.MediaLink.Host.Contains($storageAccountName)}).Count -gt 0 `
} | Select-Object -Property ImageName, ImageLabel
Remove any image
Remove-AzureVMImage -ImageName 'yourImageName'
Note: commands are classic/ASM, make sure you have module installed.
yes, you can use portal UI or powershell to break the lease (or SDK's). for the portal just click on the blob and there would be a button to break the lease. for powershell something like this:
$blob = Get-AzureStorageBlob -Context $ctx -Container %container% -Blob %blob%
$blob.ICloudBlob.BreakLease()
Related
I am using an Azure Powershell task in an Azure (VSTS) Pipeline to try and upload a file to an Azure Classic container.
As part of setting up the Azure Powershell task (ver 3.1.10), I added the Azure Classic subscription that this container lives in to the Project Settings\Service connections:
I then select that subscription in the pipeline task:
When I execute the script, the logs seem to show that the task is both setting and selecting the expected subscription:
However, if I don't explicitly (re-)create and pass in the AzureStorageContext to the Set-AzureStorageBlobContent function, the task fails with:
[error]Could not get the storage context. Please pass in a storage context or set the current storage context.
Is this expected behavior?
Is there any way around having to re-create and pass in the context when it appears that it already exists?
For example, is there an environment variable that might contain the context that was automatically created/selected that I can just pass in?
Update:
I suspect that if the
Select-AzureSubscription call seen in the logs used the -Current switch, this would work as I'm expecting it to.
However, since that command is automatically ran with no way to configure it via the pipeline task, it's not verifiable.
Perhaps this needs to be a feature request?
Excerpts from script:
#Not passing in the context results in the error
Set-AzureStorageBlobContent -File "$file" -Blob "$blobpath/$blah" -Container $blobname -Properties $properties -Force
#Passing in the context works:
$azureKey = Get-AzureStorageKey "$accountName"
$storagekey = [string]$azureKey.Primary
$context = New-AzureStorageContext "$accountName" -StorageAccountKey $storagekey
Set-AzureStorageBlobContent -File "$file" -Blob "$blobpath/$blah" -Container $blobname -Properties $properties -Context $context -Force
While I probably should just delete this question (upon discovering the "answer"), I suppose I will provide what I found after more debugging, etc.
TLDR; -- This is mostly me not grepping the concept that an Azure Subscription (context) does not correlate to an Azure Storage (context).
Is this expected behavior?
Yes.
Simply having a currently set subscription does not mean there's a currently set storage context.
Come to find out, our company has multiple storage accounts in the subscription I was using.
It could be that if a subscription only has one storage account, the function would succeed without specifying a context? Maybe I will research that later.
Is there any way around having to re-create and pass in the context when it appears that it already exists?
No (perhaps because of the multiple storage accounts in the subscription).
I will have to specify/select the current storage context from the current subscription (as I did in the "Passing in the context works" part in my question).
Here's how I arrived at this:
First, I verified what actually was being set (if anything) as the current [subscription] context and then explicitly (re-)setting it.
Running the command still failed.
So, it wasn't that the subscription wasn't being set (since it was).
$current = (Get-AzureSubscription -Current).SubscriptionName
Write-Host "current subscription is $current"
$setCurrent = $false
Write-Host "setCurrent is $setCurrent"
$setCurrent = Select-AzureSubscription -Current -SubscriptionName "CDN Subscription" -PassThru
if ($setCurrent)
{
Write-Host "current set"
$current = (Get-AzureSubscription -Current).SubscriptionName
Write-Host "current subscription is $current"
}
else
{
Write-Host "current not set"
}
It then dawned on me that maybe 'subscription' did not equal 'storage'.
To verify that, I then ran the following:
$current = (Get-AzureSubscription -Current).SubscriptionName
Write-Host "current subscription is $current"
$table = Get-AzureStorageAccount | Format-Table -AutoSize -Property #{Label="Name";Expression={$_.StorageAccountName}},"Label","Location" | Out-String
Write-Host "$table"
The result - 4 storage accounts in the subscription.
Ergo, I will need to specify the account I want to upload to
Team,
Thanks in Advance, I'm an IT pro and also learning PowerShell. I have 2 storage account Storage A and Storage B in different diff region and I want to create identical containers in the secondary storage account.
I've found below command which can get the list of all the containers in the primary storage account and then I can use the foreach loop to create the container on secondary storage. But I want to make sure that in the secondary storage account if it has the container name already then my command should skip that container and move on to create the next storage container.
Get-AzureStorageContainer -Context $storageAccountContext | ForEach-object { New-AzureStorageContainer -Name $_.Name -Context $Destinationcontext }
"VM" is incorrect argument against the "-Property" switch for the values we are getting from pipe(|).
Please use the correct name of the property. I have used "VM" above only as an example. VM is property in Esxi(VC) environment.
Please run the below command & check the output.
Get-AzureStorageContainer -Context $Destinationcontext
It should give you output something like below:
Property_ID Property_NAME Property_3
Value 1 Value_A Value_1A
Value 2 Value_B Value_2A
So, now the correct syntax should be:
$Vm_to_be_created|Select-object -Property "Property_ID"| ForEach-object { New-AzureStorageContainer -Name $_.Name -Context $Destinationcontext }
:)
Hope this helps!
$storageAccountContext ="Storage_Account_A"
$Destinationcontext ="Storage_Account_B"
$Vm_in_A =#(Get-AzureStorageContainer -Context $storageAccountContext )
$Vm_in_b =#(Get-AzureStorageContainer -Context $Destinationcontext)
$Vm_to_be_created =#(Compare-Object -ReferenceObject $Vm_in_A -DifferenceObject $Vm_in_b )
$Vm_to_be_created|Select-object -Property VM| ForEach-object { New-AzureStorageContainer -Name $_.Name -Context $Destinationcontext }
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.
I plan to backup my azure vhd files by shutting down my vm and then copying the vhd files from the production container to a backup container. How can I automate deleting vhd files that are a week old in the backup container?
If you can accept using PowerShell, then this would do it for you. It will register a scheduled job to run daily and remove PageBlob's in the container specified.
$taskTrigger = New-ScheduledTaskTrigger -Daily -At 12:01AM
Register-ScheduledJob -Name DeleteMyOldFiles -Trigger $taskTrigger -ScriptBlock {
$isOldDate = [DateTime]::UtcNow.AddDays(-7)
Get-AzureStorageBlob -Container "[YOUR CONTAINER NAME]" |
Where-Object { $_.LastModified.UtcDateTime -lt $isOldDate -and $_.BlobType -eq "PageBlob" } |
Remove-AzureStorageBlob
}
This is something not available right out of the box. You would have to write some code yourself. Essentially the steps would be:
List all blobs in your backup container. Blob list would return blobs along with its properties. One of the properties would be LastModifiedDate (this would be in UTC).
You could then put your logic to find blobs which have been modified "x" days ago. You would then go ahead and delete those blobs.
A few other things:
You mentioned that your backup container contains some VHDs which are essentially page blobs. When you list blobs, you would also get blob type so you could further filter the list by blob type (= PageBlob)
As far as automating the process go, you could either write this in a PowerShell script and then schedule it using Windows Scheduler. If you're comfortable writing node.js, you could write the same logic using node.js and make use of Windows Azure Mobile Service Scheduler.
I found this answer when trying to delete the whole container. Using Rick's answer as a template I came up with this trial what-if to determine which containers would be deleted:
$ctx = New-AzureStorageContext -StorageAccountName $AzureAccount `
-StorageAccountKey $AzureAccountKey
$isOldDate = [DateTime]::UtcNow.AddDays(-7)
Get-AzureStorageContainer -Context $ctx `
| Where-Object { $_.LastModified.UtcDateTime -lt $isOldDate } `
| Remove-AzureStorageContainer -WhatIf
Then when I was satisfied that the list should be deleted, I used -Force so as to not have to confirm every delete:
Get-AzureStorageContainer -Context $ctx `
| Where-Object { $_.LastModified.UtcDateTime -lt $isOldDate } `
| Remove-AzureStorageContainer -Force
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.