[Bug]: Failed to perform Auto-login: PSContextCredentialexec: "pwsh": executable file not found in %PATH%. about azure-pipelines-tasks

[fifuente]

@richRubie I ran the Connect-AzAccount -identity command on the target VM where the files are going to be copied to. It used the system assigned managed identity assigned to the resource. That identity is the one that needs to have access to the storage account that works as an intermediary to download the files to the VM.

[v-snalawade]

@fifuente - what is powershell version installed, Can you please update the powershell version to v7 and try running the pipeline again.

[fifuente]

@v-snalawade Let me try checking the version and will make sure v7 is installed. Will get back with the results

[fifuente]

@v-snalawade Installing PowerShell 7 kind of work. After that the task failed because none of the Az.* modules could not be found so I went ahead and install all of them - not sure which ones were required, installed everything within Az.*.

And then when re-running the task, it failed again because I had to manually connect to an Azure Account by running Connect-AzAccount. After running Connect-AzAccount -identity, then the task succeeded.

Thanks for the help!

Also, is there a way to ask for adding those extra steps in the task? To me, it sounds like those are requirements to run the AzCopy task and should at least verify that everything is in place before moving forward. Also, using Managed Identity sounds like the normal approach to me to auth to access other azure resources.

But if it is not possible, could those extra requirements at least be added to the documentation of the task to know what is needed to deploy to Azure VMs by using the AzCopy task?

[fifuente]

@v-snalawade Another issue I just found, is that the task used to copy all the binaries I needed into the VM. With the same directories and files. And with the new update, it now copies everything but within a new directory with a random guid (which is the one used to copy the files to the storage account in the middle of the process) and that breaks all of our processes since the binaries are now in a different subdirectory.

Is there a way for us to indicate to not create any new random directories at the root of the binaries we want to copy?

As an example, if you tried to deploy the following to the VM in the root of E:\

• DirectoryA
  • FileA
  • FileB

You got the following:

• E:\
  • DirectoryA
    • FileA
    • FileB
      With the new update to the AzCopy task, now you get:
• E:\
  • Random directory with a guid as a name
    • DirectoryA
      • FileA
      • FileB

[fifuente]

@v-schhabra any update on this? I was able to fix by myself the initial issue, but the task is still deploying to the VM and creating a directory with a random guid. This is breaking our data processors.

I need to know if I need to make changes to my pipelines or use another approach to deploy to get my team unblocked with this. Also, I need to know what the default behavior will be for the task to avoid breaking my pipelines again in the future.

Thanks!

[v-snalawade]

@fifuente - We are checking on it, we are trying to repro the same scenario. will keep you posted on updates.

[richRubie]

And then when re-running the task, it failed again because I had to manually connect to an Azure Account by running Connect-AzAccount. After running Connect-AzAccount -identity, then the task succeeded.

@fifuente where did you run this command, on the target vm?
What identity should it be using?

I agree why are the prequisites of powershell 7 and az.Account not advertised / checked when deploying to a VM.

Can anyone point me in the direction of the docs for deploying code to a vm using AzureFileCopyV6?

[richRubie]

So I added a managed identity to the vm and then ran Connect-AzAccount -identity
I got further but then failed to access the container....

How should this work?
It's really frustrating

[v-snalawade]

Deployments completed