Closed jnsn closed 9 years ago
I made some, but not much progress.
I noticed that running the Import-AzurePublishSettingsFile
once is enough to keep the certificate stored, even after a machine reboot. Then I could use another way to load my subscription info.
$subscriptionId = "MY_SUBSCRIPTION_ID"
$subscription = "MY_SUBSCRIPTION"
$thumbprint = "MY_THUMBPRINT"
$myCert = Get-Item cert:\\CurrentUser\My\$thumbprint
$service = "MY_SERVICE"
Write-Output "Import Azure Module"
Import-Module Azure
Write-Output "Setting Azure Subscription"
Set-AzureSubscription –SubscriptionName $subscription -SubscriptionId $subscriptionId -Certificate $myCert -CurrentStorageAccountName $service
Select-AzureSubscription -SubscriptionName $subscription
Write-Output "Getting deployment info"
$deployment = Get-AzureDeployment -ServiceName $service -Slot $slot -ErrorVariable a -ErrorAction silentlycontinue
But this also fails, with the following output:
28-Nov-2014 08:43:41 Import Azure Module
28-Nov-2014 08:43:41 Setting Azure Subscription
28-Nov-2014 08:43:41 Selecting Azure Subscription
28-Nov-2014 08:43:41 Getting deployment info
28-Nov-2014 08:58:32 An error occurred while sending the request.
28-Nov-2014 08:58:32 The request was aborted: Could not create SSL/TLS secure channel.
28-Nov-2014 08:58:32 at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
28-Nov-2014 08:58:32 at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
28-Nov-2014 08:58:32 at Microsoft.WindowsAzure.DeploymentOperationsExtensions.GetBySlot(IDeploymentOperations operations, String serviceName, DeploymentSlot deploymentSlot)
28-Nov-2014 08:58:32 at Microsoft.WindowsAzure.Commands.ServiceManagement.HostedServices.GetAzureDeploymentCommand.<OnProcessRecord>b__1()
28-Nov-2014 08:58:32 at Microsoft.WindowsAzure.Commands.Utilities.Common.ServiceManagementBaseCmdlet.ExecuteClientActionNewSM[TResult](Object input, String operationDescription, Func`1 action, Func`3 waitOperation, Func`3 contextFactory)
28-Nov-2014 08:58:32 at Microsoft.WindowsAzure.Commands.Utilities.Common.ServiceManagementBaseCmdlet.ExecuteClientActionNewSM[TResult](Object input, String operationDescription, Func`1 action, Func`3 contextFactory)
28-Nov-2014 08:58:32 at Microsoft.WindowsAzure.Commands.ServiceManagement.HostedServices.GetAzureDeploymentCommand.OnProcessRecord()
28-Nov-2014 08:58:32 at Microsoft.WindowsAzure.Commands.Utilities.Common.CloudBaseCmdlet`1.ProcessRecord()
28-Nov-2014 08:58:32 at System.Management.Automation.CommandProcessor.ProcessRecord()
Again, if I RDP onto the virtual machine and run those commands manually, they perfectly succeed. Any following run of those commands through the build script also succeeds without troubles, until the virtual machine is rebooted again.
I suspect this has to do with access to certain APIs or to the certificate store on the machine - You should conside using Add-AzureAccount - Credential instead to set up your credentials.
I posted the same question on the Atlassian forums, as I suspect there's a difference between the use of the user account when the build is triggered through the build agent, opposed to when I RDP into the virtual machine.
For now, I used a workaround to trigger the subscription file import as a scheduled task when the machine boots.
Hi There,
I am struggling mightily with this exact problem. Have you made any further progress trying to execute the powershell scripts remotely?
I too manually run the importsettings file cmdlet and it seems to stick. But once i try to do certain cmdlets remotely like Get-AzureDeployment I get the ssl error like you did. Any advice?? Stuggling for days :(
Thanks for any info!
bernie
I ended up using a startup task which imports the publish settings file when the machine booted.
I can't remember whether I just do it for the administrator, or also for the limited bamboo user account which is present on the virtual machine.
I am trying to automate Azure deployment from a Bamboo OnDemand Amazon EC2 Elastic Instance. Unfortunately, I've hit a bump in the road and I'm not quite sure why or how to solve it.
As an example, I tried the following script:
The exception info:
This script is invoked through the build system with the following command:
The weird part is that, if I RDP onto the VM with the
bamboo
user and run theImport-AzurePublishSettingsFile "C:\Users\Bamboo\azure2.publishsettings"
manually every following execution of the build script succeeds and prints out the result of theImport-AzurePublishSettingsFile
call.In order to save costs, the build server is set on a schedule to shut down between 8 PM and 7 AM which means that currently someone has to log on onto the virtual machine every day and run the command manually before any deployment succeeds. It's understandable that this is becoming a burden on our deployment process.
I know that Bamboo might be a factor in this, but I would like to understand what could be the problem and why this could occur. Could it be something with the way the script is invoked, is there a PowerShell command I must run to elevate certain permissions, ...
Thanks