'Could not get the storage context' error when using Set-AzureStorageBlobContent in VSTS Azure Powershell...












1














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 SettingsService connections:
service connection



I then select that subscription in the pipeline task:
select subscription



When I execute the script, the logs seem to show that the task is both setting and selecting the expected subscription:
logs



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









share|improve this question





























    1














    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 SettingsService connections:
    service connection



    I then select that subscription in the pipeline task:
    select subscription



    When I execute the script, the logs seem to show that the task is both setting and selecting the expected subscription:
    logs



    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









    share|improve this question



























      1












      1








      1







      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 SettingsService connections:
      service connection



      I then select that subscription in the pipeline task:
      select subscription



      When I execute the script, the logs seem to show that the task is both setting and selecting the expected subscription:
      logs



      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









      share|improve this question















      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 SettingsService connections:
      service connection



      I then select that subscription in the pipeline task:
      select subscription



      When I execute the script, the logs seem to show that the task is both setting and selecting the expected subscription:
      logs



      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






      azure powershell azure-devops






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 21 '18 at 19:12







      Gregg L

















      asked Nov 21 '18 at 18:41









      Gregg LGregg L

      138129




      138129
























          1 Answer
          1






          active

          oldest

          votes


















          1














          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"
          }


          output_1



          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



          table






          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418625%2fcould-not-get-the-storage-context-error-when-using-set-azurestorageblobcontent%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            1














            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"
            }


            output_1



            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



            table






            share|improve this answer




























              1














              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"
              }


              output_1



              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



              table






              share|improve this answer


























                1












                1








                1






                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"
                }


                output_1



                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



                table






                share|improve this answer














                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"
                }


                output_1



                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



                table







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Nov 21 '18 at 21:40

























                answered Nov 21 '18 at 21:34









                Gregg LGregg L

                138129




                138129






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418625%2fcould-not-get-the-storage-context-error-when-using-set-azurestorageblobcontent%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    404 Error Contact Form 7 ajax form submitting

                    How to know if a Active Directory user can login interactively

                    Refactoring coordinates for Minecraft Pi buildings written in Python