I have a PowerShell script running in Octopus Deploy as part of my deployment process. An extract of the script is below:
Import-AzurePublishSettingsFile "myAzurePublishSetting.PublishSettings"
Select-AzureSubscription 'mySubscription'
Set-AzureSubscription -SubscriptionName 'mySubscription' -Environment 'myEnvironment' -CurrentStorageAccountName 'myStorageAccount'
I'm now getting the below error from the Set-AzureSubscription cmdlet:
ServiceEndpoint and ResourceManagerEndpoint values do not match existing environment. Please use Environment parameter.
at Microsoft.WindowsAzure.Commands.Profile.SetAzureSubscriptionCommand.ExecuteCmdlet()
at Microsoft.WindowsAzure.Commands.Utilities.Common.AzurePSCmdlet.ProcessRecord()
Octopus Deploy is hosted in an Azure virtual machine. This script worked fine until a few days ago so maybe Azure has changed something since nothing else has changed.
It's even more puzzling since I can run this script successfully on the virtual machine in both a PowerShell window and using Calamari.exe which is apparently what Octopus uses under the hood to call the script.
Any ideas?
This can happen if you have made changes to Azure subscriptions, for example disabling a subscription. Powershell still has a cache of the previous subscriptions. Use Get-AzureAccount to get the Id of the account and then Remove-AzureAccount. Finally, add the account again using Add-AzureAccount.
Related
I have a need to list down all the database names of a particular server on Azure.
$databases = Get-AzSqlDatabase -ServerName servername -ResourceGroupName resourcegroupname
foreach($dbs in $databases)
{
$dbs.DatabaseName
}
this script works well run from local.
My question is how to run this from an Azure DevOps release using the powershell task?
You have to use the Azure-Powershell task.
That way the pipeline can connect to the Proper Azure Subscirption, just like you connected to the Subscription manually from Powershell
Details about the Azure Powershell Task: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-powershell?view=azure-devops
But them I wonder what you want to do with the List of the databases.
Going out on a limb here, but you'd probably want the output back in the Pipeline. In which case please check out
https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/preview/outputvariable.md
Write-Host "##vso[task.setvariable variable=var01;isOutput=true]123"
I am working on developing a Automated QA script for my project for my organisation. My goal is to execute pester scripts through custom script extension feature of azure vms. I got the Pester executed and result exported as a nunit xml. I would like to fetch the xml back from VM to my local machine. One way of doing that is by uploading the xml into blob storage from VMs. but since it requires azure connection to be established in VM using SP account. I dont prefer this method.
I would like to know the best way to retrive pester results and get it outside VM.
Any help is much appreciated. Thanks .
I'd use a shared access signature token for that (link). that way your script doesnt really need SP, it just needs the token. that token would limit permissions to only upload file to specific container (or even blob).
$sascontext = New-AzureStorageContext -StorageAccountName accountname -SasToken '?tokenvalue'
Set-AzureStorageBlobContent -File path -Container name -Context $sascontext -Force
You can create new token with New-AzureStorageBlobSASToken or New-AzureStorageContainerSASToken
Your only requirement would be to install Azure.Storage module before hand.
Context
I have a Microsoft account, an I have and Azure subscription for it. I've got access rights (added as user: owner) to other Microsoft account's other subscriptions.
All works OK, when I log with my one and only credential in to the Azure portal, I can see the directories (tenants?) listed in the top right menu, so I can switch. After switching to a directory I can see the subscription(s) for that directory.
I would like to use this credential similarly in PowerShell. So far I used Select-AzureRmSubscription with success, and interestingly I experienced, that I can omit -TenanttId parameter even the subscription is under other tenant as my default directory. (I suppose Select-AzureRmSubscription iterates though all the tenant's all subscriptions to find the guid I providing in -SubscrptionId parameter. (or was this only a "bug"?). Anyway now I've switched to an other client computer, and freshly installed AzureRM PowerShell modules, and the very same Select-AzureRmSubscription does not work there. So I thought this "bug" was "fixed" and now I must use the -TenantId parameter too. However I still got error.
NOTE: All works from my older developer machine: I can switch between subscriptions of different tenants just by using Select-AzureRmSubscription (even not using -TenantId parameter)
What I've tried:
$subscriptionId = "42940206-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$tenantId = "ce8a477c-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionId $subscriptionId -TenantId $tenanId
I've got the following error message:
Set-AzureRmContext : Cannot validate argument on parameter 'SubscriptionId'. The argument "42940206-xxxx-xxxx-xxxx-xxxxxxxxxxxx" does not
belong to the set "0692a8b8-xxxx-xxxx-xxxx-xxxxxxxxxxxx" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.
What is this 0692a8b8-xxxx-xxxx-xxxx-xxxxxxxxxxxx" specified by the ValidateSet attribute. It is neither any of my subscription ids, neither any my tenantIds...
Differences between the two client machines
Working: Poweshell 5, approx half year old AzureRM modules, installed by PowerShellGet's Install-Module
Not Working: Poweshell 4, latest AzureRM modules, installed by PowerShellGet's Install-Module
The trivial next step would be to install PowerShell 5 on the new machine, but it is a production machine many of stabilized and day by day running PowerShell scripts, so I would not like to risk to break the production processes...
I ran into similar issue. I was only experiencing the issue if the subscriptions were in different tenants.
The cure, for me, was to get the subscription object, then select it. So, using your example above, where you have $subscriptionId setup with your subscription ID value you want, you'd do:
Get-AzureRmSubscription -SubscriptionId $subscriptionId | Select-AzureRmSubscription
I'm trying to use the Windows Azure PowerShell module to manage a subscription.
I have downloaded my certificate (the .publishsettings file) and imported it with Import-AzurePublishSettingsFile and then I've selected my subscription with Select-AzureSubscription neither of which gave errors.
I've also set my subscription using Set-AzureSubscription -SubscriptionName "Blah"
Still, I get a
Get-AzureService : Value cannot be null.
Parameter name: subscriptionId
when running Get-AzureService
I've read getting started guides and various documentation but I can't work out what I'm doing wrong. Which in my mind, makes this a UX problem that Microsoft should address.
Update
I got a bit further, I used
Set-AzureSubscription -SubscriptionName "Blah" -SubscriptionId 0123
which changed the error from Get-AzureService to:
Get-AzureService : Value cannot be null.
Parameter name: managementCertificate
But now I cannot set my certificate since the argument wants an X509Certificate type.
There is a better way to authenticate when using the Azure Powershell cmdlets --- Add-AzureAccount. This will prompt you for your login credentials instead of using the service management certificate.
You may still run into some issues because Azure powershell caches your subscriptions in XML files in %appdata%\Windows Azure Powershell.
I would recommend:
Close the Azure Powershell window
Delete the XML files in %appdata%\Windows Azure Powershell.
Open Azure Powershell and run Add-AzureAccount.
This should ensure that you have the correct subscriptions configured.
I hope this might help you-
Add-AzureAccount
Get-AzurePublishSettingsFile
Import-AzurePublishSettingsFile filenamewithpath
filenamewithpath is the publishsetting file with path saved on your pc
I'm using the Windows Azure PowerShell Cmdlets v0.6.7 from here: https://www.windowsazure.com/en-us/manage/downloads/
When I run the following command:
Move-AzureDeployment -ServiceName $AzureServiceName
I get the following error:
Move-AzureDeployment : There was no endpoint listening at https://management.core.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/services/hostedservices/xxxxxxxxxxxxxxx/deploymentslots/Production that could accept the message.
The error is somewhat correct, there is only a deployment in my Staging slot. However, the documentation for Move-AzureDeployment (http://msdn.microsoft.com/en-us/library/windowsazure/jj152834.aspx) states:
If there is a deployment in the staging environment and no deployment
in the production environment, the deployment will move to production.
The preceding Azure PowerShell Cmdlets in the same script, such as New-AzureDeployment, execute successfully. I start the script by using Set-AzureSubscription to configure the subscription info and certificate.
Not sure what I'm missing, any help is appreciated, thanks!
I ran into this issue as well and resorted to using the REST API for swapping. Here is a sample in case anyone is interested.
$webRequest = [System.Net.WebRequest]::Create("https://management.core.windows.net/$global:SubscriptionId/services/hostedservices/$serviceName")
$webRequestContent = ("<?xml version=""1.0"" encoding=""utf-8""?><Swap xmlns=""http://schemas.microsoft.com/windowsazure""><Production>{0}</Production><SourceDeployment>{1}</SourceDeployment></Swap>" -f $productionDeploymentName, $stagingDeploymentName)
$webRequest.Method = "POST"
$webRequest.ClientCertificates.Add($global:ManagementCertificate)
$webRequest.ContentType = "application/xml"
$webRequest.ContentLength = $webRequestContent.length
$webRequest.Headers.Add("x-ms-version", "2012-03-01")
$writer = New-Object System.IO.StreamWriter($webRequest.GetRequestStream())
$writer.Write($webRequestContent)
$writer.Close()
$webResponse = $webRequest.GetResponse()
WaitForDeploymentState $serviceName 'Production' 'Running'
WaitForRoleInstancesState $serviceName 'Production' 'ReadyRole'
I think there is a bug. I created an issue here:
https://github.com/WindowsAzure/azure-sdk-tools/issues/785
I found this when I hit the same problem.
In my script, if I want to run the Move-AzureDeployment I first check the Production slot, if it has content then I switch (having already deployed to staging earlier in the script).
In the case where Production is empty I re-deploy the current package to the Production Slot, I could optimize it to use the azure storage but it'll do for today.
In short; the docs are either wrong or there is a bug, you cannot use this cmdlet if Production is empty.