I am using a automation account runbook to compare files within a storage account fileshare and have been trying to use Get-AzStorageFileContent to download them so I can then compare.
However, I get the error: "Get-AzStorageFileContent : Can not find your azure storage credential. Please set current storage account using "Set-AzSubscription" or set the "AZURE_STORAGE_CONNECTION_STRING" environment variable."
When I google "Set-AzSubscription" it doesn't appear to exist but I am directed to Set-Azcontext which I have tried to use to set the context to the subscription the storage account is in but this produces the either the same error when testing in powershell ISE or the erorr "please provide a valid tenant or a valid subscription" in the runbook (even though I am using the correct IDs for both)
I have noticed that the storage account is in a different subscription to the runbook could this be breaking it? It does allow me to save files to the storage in the same script so I'm not sure why it would break here.
I am authenticating with a managed identity if that's relevant.
My code to get the file looks like this:
try{
write-output "get file"
Set-Azcontext -Subscription "--storage account subscription--" -Tenant "--Our tenant--"
Get-AzStorageFileContent -ShareName "--storage account name--" -Path "--path of file--"
}
catch{
Write-Output "couldn't get file"
Write-Warning $_.Exception.Message
break
}
Get-AzStorageFileContent : Can not find your azure storage credential. Please set current storage account using "Set-AzSubscription" or set the "AZURE_STORAGE_CONNECTION_STRING" environment variable:
I also got the same error when I tried in my environment.
This issue usually occurs if you do not create a storage context by specifying a storage account name and storage account key, which is required for storage account authentication.
I tried below script in Azure runbook, and it worked successfully as detailed below:
Connect-AzAccount
Set-AzContext -Subscription "<SubscriptionID>"
$context = New-AzStorageContext -StorageAccountName "<StorageAccountName>" -StorageAccountKey "<StorageAccountKey>"
Get-AzStorageFile -ShareName <FileshareName> -context $context
Output:
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
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
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.