Since last month I am doing successful deployment on azure using visual Studio on Azure function App but suddenly I am start getting error while deploying.
Web deployment task failed. (Unable to perform the operation ("Create File") for the specified directory ("D:\home\site\wwwroot\bin\extensions.json")
I tried following things but in vain.
I restarted my Function app
Reset the publish key
Updating file (MobiMatterUsers\bin\extensions.json). C:\Program
Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeploy.targets(140,5):
error : Web deployment task failed. (Unable to perform the operation
("Create File") for the specified directory
("D:\home\site\wwwroot\bin\extensions.json"). This can occur if the
server administrator has not authorized this operation for the user
credentials you are using.
Kindly provide me possible solution and brief explanation why i am getting this error
Use IAM in the portal to see if you have the required rights.
Then rename the old file as it may be locked by a process.
if that doesn't work, check it local deployment still works.
Related
Inside the Synapse Studio Access Control page, the screen shows:
Failed to load
Failed to load role assignments due to server error, error code 500. Refresh or troubleshoot the issue.
As far as I can tell, no one setup the Synapse Administrator or any other roles within the studio itself.
I cannot add the Synapse Administrator. When I attempt to, I get another 500 error:
"body": "{"error":{"code":"HttpWrapOperationAsyncFailed","message":"System.Exception : No RoleAssignment for workspace :
I've also tried it through the CLI and got a similar error there as well.
I'm afraid that something went wrong with the deployment of the resources related to this Synapse workspace, but I don't see anything wrong within the portal. Help?
After a successful build using a hosted VS2017 agent, I'm trying to deploy on-prem using an local hosted agent which was setup using a domain account which should have sufficient permissions as it is in the local admin group. As I was digging around on this issue elsewhere, one user re-installed their agent using NTATHORITY\SYSTEM and it worked.
I d'ont really need to create or stop\start the website, just deploy the recent build artifact.
What permissions should I check or should I use another task?
019-04-06T21:03:10.3898646Z ERROR ( message:Configuration error
2019-04-06T21:03:10.3899503Z
2019-04-06T21:03:10.3899791Z Filename: redirection.config
2019-04-06T21:03:10.3900026Z 2019-04-06T21:03:10.3900293Z Line
Number: 0 2019-04-06T21:03:10.3900530Z 2019-04-06T21:03:10.3900852Z
Description: Cannot read configuration file due to insufficient
permissions 2019-04-06T21:03:10.3901076Z 2019-04-06T21:03:10.3901333Z
. ) 2019-04-06T21:03:10.8135484Z ##[error]Process 'appcmd.exe' exited
with code '5'.
An agent is running under a user. The error means that your user doesn't have permissions to read/modify the redirection.config file that is necessary to manage IIS.
You have multiple options to solve this.
Change the user were the agent is running under. In example: NTATHORITY\SYSTEM
Give permissions to the user were your agent is running under to the folder C:\Windows\System32\inetsrv\config. If you want to create app pools or websites etc, modify permissions are of course needed.
When we install Azure agent as a service(In Windows, search for 'Services' and look for something like Azure Pipelines Agent..), by default it is logged on as 'Network Service'. Change it to 'Local System' and the pipeline should be able to run IIS related tasks/commands.
Currently, trying to configure a release pipeline in Azure Devops. I've successfully created a CI pipeline that is working and running tests successfully. My release pipeline uses the artifacts from latest the CI build and should be deploying to azure. When I look at the logs I can see the the following were completed successfully:
Initialize Agent
Initialize job
Download arifact
and then the "Deploy to Azure App Service" fails with the logs showing the following details:
2019-02-07T19:06:57.5433805Z Got service connection details for Azure App Service:'MyApp'
2019-02-07T19:06:57.5487495Z ##[error]Error: Failed to get resource ID for resource type 'Microsoft.Web/Sites' and resource name 'MyAPP'. Error: Could not fetch access token for Managed Service Principal. Please configure Managed Service Identity (MSI) for virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400, status message: Bad Request
2019-02-07T19:06:57.5496340Z Failed to add release annotation. TypeError: Cannot read property 'getApplicationSettings' of undefined
I haven't been able to find much to help with this so far. I created the release pipeline by selecting Azure App Service deployment from the templates for stage 1 of the pipline (I only have one stage) and I added an artifact who's source is from my build pipeline. I then selected the Tasks tab and selected my Pay-as-you-go subscription under "Available Azure Service Connections". After selecting my subscription, my app service name became available in the "App service name" dropdown and I selected it. I then hit save and tried to create a release but every release fails with the above error message.
What can I do to overcome this?
Finally found a solution to my issue. The problem was in the way I set up my service connection. I went to:
project settings -> service connections -> new service connection -> selected azure resource manager -> selected service principal authentication INSTEAD OF managed identity authentication -> a popup came up that allowed me to log in and authorize.
Then I used that service connection when creating the release pipeline instead of the pre-existing Pay-As-You-Go subscription that I used last time.
Previously when I tried this, I had an adblocker running and it blocked the popup which allowed me to authorize when I selected service principal authentication. That resulted in an "Unable to authorize account" error message which is why I went with managed identity authentication in the first place.
In my case, it was related to a chrome extension I have added 'enable CORS' plugin. After disabling, release pipeline worked nicely
I'm trying to deploy an HDInsight cluster using an ARM template via Visual Studio. I've created an Azure Resource Group project in Visual Studio 2015, and added my resource definitions to the template JSON files.
However when I've gone to deploy it (by right-clicking the project, choosing Deploy -> New Deployment, entering my parameters), the output of Visual Studio shows (I've snipped out some boring stuff):
17:19:23 - Build started.
17:19:23 - Project "LaunchHdInsightCluster.deployproj" (StageArtifacts target(s)):
[snip]
17:20:27 - [VERBOSE] 17:20:27 - Resource Microsoft.HDInsight/clusters 'groupbhdinsight' provisioning status is running
17:31:06 - [ERROR] New-AzureRmResourceGroupDeployment : ExpiredAuthenticationToken: The access token expiry UTC time '3/14/2016 5:31:06 PM' is earlier than current UTC time '3/14/2016 5:31:07 PM'.
Note that the deploy only ran for 12 minutes before the access token expired - obviously for deploying an HDInsight cluster this is a problem (takes on average 20 minutes).
I'm just trying to understand what's going on under the hood here, as I can't find documentation for this. i.e:
What creates the access token and how? How long does it last for? I wasn't asked for any Azure creds when deploying - I'm assuming it must be the fact that I'm signed into Visual Studio using the same account I use in Azure, and it 'borrows' the authentication session, but this is just a guess
What determines the expiry time of the access token so I can prevent this happening again?
How do I refresh my authentication token?
What's happening here is that the Azure Resource Group deployment in VS uses the PowerShell Script in the project to do deployment (even though the output is hosted in VS, we use that PS script to do the work). The PowerShell script is authenticated by using the token from your VS sign in. That token is only good for an hour and then VS will refresh it. Once it's handed off to PowerShell though, PowerShell doesn't automatically refresh it. So if you have the token for 59 minutes, it's going to expire soon after you start the deployment. The token could last for an hour, or anything less than that. We're working on a fix for this (i.e. have PowerShell automatically refresh the token) but that's a month or so out yet. See: https://github.com/Azure/azure-powershell/issues/1068
Workarounds: Unfortunately there's no good work around from VS. But...
As observed the deployment will continue just fine in Azure, it's just that VS/PS can no longer poll for status. You can monitor the deployment via the portal or PowerShell.
If you drop to PowerShell and run the script, PowerShell will automatically refresh the token when you login with credentials - you can get the exact command that VS runs by sifting through the output window - this doc also gives an overview of running the script manually: https://azure.microsoft.com/en-us/documentation/articles/vs-azure-tools-resource-groups-how-script-works/
Hope that helps...
I bet it was a transient issue. I retried deployment (needed to modify my ARM template) and now it succeeded.
Please check your Azure Resource Group in the portal. You will likely have your resources up and running.
#Cleverguy25 provided an explanation of how I believe the deployment process work.
I am not sure, but I believe that the New-AzureRmResourceGroupDeployment uploads your template file and sets up a deployment to happen in the cloud. Then it queries the deployment to see if it is done and outputs the resources as they are created. Obviously those queries error when the token expires. But the deployment should continue.
You could ignore this error and query the deployment or resource group yourself, to see when it is done.
I follow this post, and simply execute 'Clear-AzureRmContext' this command, then reconnect to Azure, using 'connect-AzAccount', the issue resolved.
https://github.com/Azure/azure-powershell/issues/6585
Open a new powershell and get the current metadata used to authenticate Azure Resource Manager requests using Clear-AzureRmContext.
This worked the magic for me.
I am getting the following error when I run Continuous Deployment in TFS:
The polling operation Upgrade Deployment failed with the error: (400)
BadRequest.
Error Code: BadRequest
Message: Your role instances have recycled a number of times during an
update or upgrade operation. This indicates that the new version of
your service or the configuration settings you provided when
configuring the service prevent the role instances from running.
Verify your code does not throw unhandled exceptions and that your
configuration settings are correct and then start another update or
upgrade operation.
Also, I have checked the VM on where the build is and on the Microsoft.Compute.VMAccessAgent extensions I got this error:
Cannot update Remote Desktop Connection settings for built-in
Administrator account. Error: Object reference not set to an instance
of an object.
Has anyone come across this? The build continues to run and does not stop.
The "Your role instances have recycled a number of times during an update or upgrade operation" error message is always prompted when Windows Azure SDK is upgraded. The workaround is go to Project Properties and upgrade to the correct version SDK.
Please have a check on this blog for the thoughts on how to trouble shoot it:
http://blogs.msdn.com/b/cie/archive/2013/12/21/role-just-recycles-after-sdk-upgrade.aspx
Also a blog series about troubleshooting on common issues: Your role instances have recycled a number of times during an update or upgrade operation