Azure ExpiredAuthenticationToken during New-AzureRmResourceGroupDeployment when deploying resources via Visual Studio - azure

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.

Related

Request timing out when exporting Azure resource group in powershell

I want to export an ARM template for a resource group in Windows Azure. I'm using the Azure Powershell module.
Whenever I try to export the resource group using Export-AzResourceGroup, the cmdlet fails with the following error:
Export-AzResourceGroup : Operation failed because a request timed out.
I have inspected the web traffic with Fiddler and I can see that the actual HTTP call to Azure is completing successfully, it's just taking a long time. So it's not a matter of e.g. extending the timeout on the ServicePointManager.
Is there any solution or work-around to stop this cmdlet timing out?
This issue maybe occurring due to a previous version of Az powershell module. Please update your Az module to the latest version and try again.
Also make sure you have the write permissions in the directory you are trying to create the json file.
Meanwhile, you can create the template from the portal just to check if the json file is getting created successfully:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/export-template-portal#export-template-from-a-resource-group

Azure Automation Update Managemet schedules can be removed using powershell, but they still exist in the portal

If I used Get-AzAutomationSchedule for my automation account, I get nothing in return because I used Remove-AzAutomationSchedule for all of them. But if I look in the portal, every schedule I've deployed is there present. If I select a schedule that I've removed using Powershell and then attempt to update the schedule in the portal, I get the crying rain cloud and it says
NewScheduleBladeV2
MICROSOFT_AZURE_AUTOMATION
NewScheduleBladeV2
The reacurrance is also listed as unknown in the list.
This is a problem not only for clarity when viewing in the portal, but if I attempt to run my ARM template again with the schedules there, I get an "Internal Server Error" code 500. I can't redeploy them if I delete them with Powershell.
Is there anyway to send something to Azure to update these? Not sure if I need to do some API call or some form of Set-Az cmdlet
Thanks
I have tried to reproduce the issue you are facing but all worked good for me when i used cmdlets Get-AzAutomationSchedule and Remove-AzAutomationSchedule of Az.Automation module versioned 1.2.1.
Is this still an issue at your end ? If yes, can you restart the browser after clearing the cache and deleting the cookies ?

Many Azure PowerShell commands fail: Must specify valid information for parsing in the string

Today we tried to deploy new build to our staging environment which based on Azure Web Apps using our release flow which normally runs good and requires to push one button. but today something is going wrong with Azure. the commands like Get-AzureWebSiteJob, Switch-AzureWebSiteSlot, Start-AzureWebsiteJob go crazy and return error like:
"Start-AzureWebsiteJob : Must specify valid information for parsing in the string."
after second third fourth attempt error is gone but is it normal situation ? and we should handle that using retry strategy ? or something went wrong with likely Service Management cmdlets?
It is really sad to see that because you never know when Azure cmdlets would like to go down....
PowerShell 5.0
Azure PowerSherr Module 4.3.1
Subscription in North Europe
Command:
Start-AzureWebsiteJob -Name "lms365-dirreader-prod-northeuropestage" -JobName "DirectoryReader-OnSchedule"

Cancelling azure resource manager deployment

Recently I've started creating a new resource group but it seems to be stuck at provisioning server farm resource.
Restarting deployment outputs the following error:
New-AzureResourceGroup : DeploymentActive: Unable to edit or replace deployment 'App': previous deployment from '8/26/2015 8:48:55 AM' is still active (expiration time is '9/2/2015 8:48:54 AM').
I have no time to wait for its expiration. Is there a way to cancel Azure ARM deployment?
Stop-AzureRmResourceGroupDeployment should cancel the deployment and preserve the resourcegroup if you need to go that route.
https://learn.microsoft.com/en-us/powershell/module/azurerm.resources/stop-azurermresourcegroupdeployment
You can use the Remove-AzureResourceGroup cmdlet. It will start deleting the resources and cancel the deployment. However, the best way to avoid waiting for anything is to deploy with a different name, and let the delete run in the background.
https://msdn.microsoft.com/en-us/library/dn654585.aspx
Since Microsoft is retiring the AzureRm module, the new command looks like this:
Stop-AzDeployment
https://learn.microsoft.com/en-us/powershell/module/az.resources/stop-azdeployment?view=azps-9.1.0

Azure / SharePoint Server Farm Failing

I am attempting to create a SharePoint Server Farm using the option via the New menu in Azure. I've tried like 5 times now and each time, it fails after about an hour.
The error is so cryptic that I cannot figure out exactly what is going on.
The operation name is: Microsoft.ClassicCompute/virtualMachines/extensions/write
The status is: Failed
And then another,
The operation name is: Update deployment
The status is: Failed.
Thoughts?
I've had a similar experience using the "new" preview portal when deploying Databases. This portal uses Resource Manager to deploy it's resources which is a new way of doing things. Anyhow, I used the PowerShell command:
Get-AzureResourceGroupLog -Name ResourceGroupName
This provided me the detail to understand what was happening with the deployment. I had to adjust my Datacenter because the one I was trying to use was hot.
I talk a little more about the other options this command has here:
http://devian.co/?p=1181

Resources