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.
Related
I have an application hosted in Azure, and I use Azure DevOps to manage my build and release pipelines. As part of the release, I warm up the application by making a request to the root url (e.g. https://myapp.azurewebsites.net). In order to make this request I must first make sure the hosted build agent running the deployment has access to that url (or I will get a 403). I have written a short powershell script to achieve this, and put it in an Azure Powershell task. It adds the IP of the build agent to the IpSecurityConfiguration of the app service. So far so good. It works perfectly for apps that are just apps. Where it falls down is when I try to use it against a staging environment. When we release to production we first push the code to a staging slot, then flip it over to live when we've run our tests and made sure everything is good. The powershell script that correctly handles the IpSecurityConfiguration for the app services does not work on the staging slot. To access a staging slot, we use myappname/slots/staging for the variable $(WebApiName), normally it would just be the name of the app service itself. Again, this works perfectly if I run the script from my local environment, it only fails in the pipeline. The code is below:
# Whitelist Azure Agent IPs
$agentIP = Invoke-RestMethod http://ipinfo.io/json | Select -exp ip
Write-Host "Connecting to Azure"
$APIVersion = ((Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Web).ResourceTypes | Where-Object ResourceTypeName -eq sites).ApiVersions[0]
Write-Host "API Version is $APIVersion. Getting web app config for $(WebApiName) in $(ResourceGroupName)"
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites/config -ResourceName $(WebApiName) -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
Write-Host "Got web app config: $WebApiConfig"
$webIP = [PSCustomObject]#{
ipAddress = "$agentIP/32";
action = "Allow";
tag = 'Default';
priority = 300;
name = $agentIP.ToString();
description = $agentIP.ToString()
}
Write-Host "Adding $agentIP to security restrictions"
$WebApiConfig.Properties.ipSecurityRestrictions += $webIP
Write-Host "Updating security restrictions"
# update app restrictions, do not prompt for confirmation
$result = Set-AzureRmResource -ResourceId $WebApiConfig.ResourceId -Properties $WebApiConfig.Properties -ApiVersion $APIVersion -Force
To muddy the water somewhat, I can get the exact same code to work perfectly with the staging slot locally by changing
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites/config -ResourceName $(WebApiName) -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
to
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites -ResourceName $(WebApiName)/config -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
but this doesn't work in the Azure Powershell task. Instead I can't deploy to any environment because the task fails while trying to access IpSecurityRestrictions on the $WebApiConfig object. The exception is "Exception setting "ipSecurityRestrictions": "The property 'ipSecurityRestrictions' cannot be found on this object. Verify that the property exists and can be set."
As I said earlier, if I run the script in exactly this form locally, it works perfectly. Obviously I have to manually replace the variables that come from the build pipeline, but otherwise there is no difference between code that works exactly as I want it to on my local machine and code that fails in the release. You can verify this by swapping out $(WebApiName) for a valid app service name and $(ResourceGroupName) for the resource group that app service is in. I put a line in about halfway down that outputs $WebApiConfig so that I can see what it is, and on my local machine I see a valid object, while in the output of the task I get nothing. The line just says "Got web app config:"
Anyone got any ideas?
I've tried changing the version of powershell used by the task to
match the version I've got.
I've tried using the preview version of the task (v4, otherwise I've been using v3).
I've tried every permutation of /sites/config everywhere I can think of in the call to Get-AzureRmResource (since that was what allowed it to work locally on the slot).
Just one final thing in case anyone wonders. I'm doing it this way instead of whitelisting all the IPs in Microsoft's list (https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653) for two reasons, firstly it's a lot easier to maintain a short list of our own IPs, and secondly there seems to be a bug somewhere in the way Azure handles those CIDR definitions because IPs that are categorically in those ranges are frequently blocked during our deployments even when we have the entire file whitelisted. This way I just add whichever IP is currently being used dynamically to the whitelist, and remove it after we're done. Assuming I can get it to work...
Finally figured out the solution to this. In order to work with slots the resource type has to be subtly different. This line works in an Azure Powershell task:
$WebApiConfig = (Get-AzureRmResource -ResourceType Microsoft.Web/sites/slots/config -ResourceName $(WebApiName) -ResourceGroupName $(ResourceGroupName) -ApiVersion $APIVersion)
Posting in case it helps anyone else with the same issue. I can confirm that the approach I've taken works great in managing access to Azure sites by build agents, and saves a lot of messing around with Microsoft's build agent xml file.
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.
I am trying to connect to an Azure Run As connection, as part of a Powershell script that does a backup of a database.
This script attempts to call Get-AutomationConnection
As seen in the screenshot, Get-Module does return that Azure / Azure.Storage and AzureRM shows.
What module should I import in addition for this to work?
If you want to connect to an Azure Run As connection from Windows PowerShell, you should use New-AzureRmAutomationConnection.
$ConnectionAssetName = "AzureRunAsConnection"
$ConnectionFieldValues = #{"ApplicationId" = $Application.ApplicationId; "TenantId" = $TenantID.TenantId; "CertificateThumbprint" = $Cert.Thumbprint; "SubscriptionId" = $SubscriptionId}
New-AzureRmAutomationConnection -ResourceGroupName $ResourceGroup -AutomationAccountName $AutomationAccountName -Name $ConnectionAssetName -ConnectionTypeName AzureServicePrincipal -ConnectionFieldValues $ConnectionFieldValues
You are able to use the script to create the connection asset because when you create your Automation account, it automatically includes several global modules by default along with the connection type AzurServicePrincipal to create the AzureRunAsConnection connection asset.
Get-AutomationConnection runs in Azure runbook internally.
Please refer to connection assets in Azure Automation.
If you want similar functionality to runbooks on-premise, you can install AzureAutomationAuthoringToolkit. It will give you very similar functionality. I have one script that logs in using the service principal, whether it is running on-premise or in an Azure runbook. It uses the resources provided by AAATK when running on-premise, that simulate a runbook.
I did try using the version of Get-AutomationConnection that comes with the "Microsoft Monitoring agent" (Hybrid worker), but I have since read that it is different to the one that comes with AzureAutomationAuthoringToolkit, detailed in the "Known Issues" in the GitHub readme. I couldn't get it to work, so I reverted to AAATK's version.
I'm trying to move some of my resources (Azure Web Apps, Azure SQLs, Redis caches) from one resource group to another. I'm using the Azure Resource Manager PowerShell cmdlets.
Here's what I've tried:
PS C:\> Move-AzureResource -DestinationResourceGroupName NewResourceGroup -ResourceId "/subscriptions/someguid/resourceGroups/Default-Web-WestEurope/providers/Microsoft.Web/sites/somesite"
Or:
PS C:\> Get-AzureResource -ResourceName somesite | Move-AzureResource -DestinationResourceGroupName NewResourceGroup
Or:
just Move-AzureResource, hitting enter and supplying the parameters one by one.
None of the commands seems to work. They just don't do anything. No error, no output.
When I changed the debug preference to $DebugPreference = "Continue" I got only the following:
DEBUG: 12:16:06 - MoveAzureResourceCommand begin processing with ParameterSet '__AllParameterSets'.
DEBUG: 12:16:06 - using account id 'my#account.tld'...
Please note that I'm able to create a new resource group (New-AzureResourceGroup), list resource groups (Get-AzureResourceGroup), list resources (Get-AzureResource), etc.
Note: you have to call Switch-AzureMode AzureResourceManager before you can use the cmdlets. The authentication is done by Add-AzureAccount.
Articles I've been referring to:
Moving resources between Azure Resource Groups
Move-AzureResource
Using Azure PowerShell with Azure Resource Manager
GitHub - Using Azure PowerShell with Azure Resource Manager
Reading this azure forum it looks like they have implemented the cmdlet but not all resources support being moved yet.
We have released a new powershell cmdlet to move resources across resource groups. Not all resources have support yet, but the "main" ones do like hosted services, virtual machines & storage accounts.
Looking back at the example I was following, this does only use VM's. So based on this I think websites aren't supported yet. That fact that no error or warning is returned for unsupported resources is a bit poor.
Though not all resources are currently supported, I understand the current version - 0.9.1 - does have a bug which means that even a supported resource may not be moved with the symptoms as seen by the author of the question. I understand this is being worked on for the next release, but in the interim (as a temp. work around) the previous powershell cmdlets release of 2 versions ago should work fine. https://github.com/Azure/azure-powershell/releases
The original issue is fixed in the 0.9.4 release. I just tried and it works.
FYI. To move a VM using Move-AzureResourceGroup you need to move the containing cloud service and all its VMs at the same time. For example:
Get-AzureResource -ResourceGroupName OriginalResourceGroup | where { $_.ResourceType -match 'Microsoft.ClassicCompute' } | Move-AzureResource -DestinationResourceGroupName NewResourceGroup
By default, the resources in a cloud service are put in a resource group with the same name as the DNS name of the cloud service.
For some reason, Azure PowerShell Version 1.0 has trouble moving over web apps from one Resource Group to another. If you follow the instrctions below, you will be able to move the web app over via powershell.
Download Azure PowerShell Version 1. The below instructions only work for this version. Type the commands below in order.
1) **Login-AzureRmAccount** (a login window will pop up asking for your azure credentials, type them in)
2) **Get-AzureRmResource -ResourceGroupName "NameOfResourceGroup" -ResourceName "WebAppName"** (if you are moving over a website, you will see 2 files, you need the one that is a resource type of Microsoft.Web/sites)
3) **Get-AzureRmResource -ResourceGroupName "NameOfResourceGroup" -ResourceName "WebAppName" -ResourceType "Microsoft.Web/sites"**
4) Assign value 3 to a variable of your name choice. I Chose $a, so **$a = Get-AzureRmResource -ResourceGroupName "NameOfResourceGroup" -ResourceName "WebAppName" -ResourceType "Microsoft.Web/sites"**
5) **Move-AzureRmResource -DestinationResourceGroup "DestinationResourceGroup" -ResourceId $a.ResourceId**
6) It will ask you if you are sure type "Y" and hit enter.
I have an Azure VM and I'm trying to delete it using Powershell. I also want to remove the disk that that VM OS was on (there are no data disks).
I assume I'm going to need the following two cmdlets:
Remove-AzureVM
Remove-AzureDisk
Here's my code:
$VMs = Get-AzureVM $svcName
foreach ($VM in $VMs)
{
$OSDisk = ($VM | Get-AzureOSDisk)
if ($VM.InstanceStatus -eq "ReadyRole") {
Stop-AzureVM -Name $VM.Name -ServiceName $svcName
}
remove-azurevm -ServiceName $svcName -Name $VM.Name
Remove-AzureDisk -DiskName $OSDisk.DiskName
}
When I execute this the call to Remove-AzureVM returns successfully but the call to Remove-AzureDisk returns an error:
Remove-AzureDisk : BadRequest: A disk with name
XXX is currently in use
by virtual machine YYY running within hosted service
ZZZ, deployment XYZ.
Strange thing is, I can issue the same call to Remove-AzureDisk just a few moments later and it returns successfully.
Its as if the call to Remove-AzureVM is returning too quickly. i.e. Its reporting success before the VM has been fully removed, or before the link to the disk has been removed at any rate.
Can anyone explain why this might be and also how I might work around this problem?
thanks in advance
Jamie
What's happening here is that the Disk that is stored in BLOB storage is locked when in use by a VM. You are removing the VM, but it takes a few moments for the Lease on the BLOB to release. That's why you can remove it a few moments later.
There are a few folks who have written PowerShell to break the lease, or you could use PowerShell to use the SDK (or make direct REST API calls) to check lease status.
I ended up writing a script that creates a VM, clones it, then deletes the clones. As part of that I needed to wait until the lease was released hence if you're experiencing this same problem you might want to check my blog post at http://sqlblog.com/blogs/jamie_thomson/archive/2013/11/04/clone-an-azure-vm-using-powershell.aspx as it'll have some code that might help you.
Regards
Jamie
I puzzled at this for quite a while. Ultimately, I found a different command to do what I thought I was doing with this command. I would recommend the remove-azuredatadisk command to delete a disk, as it automatically breaks the lease.
Get-AzureVM -ServiceName <servicename> -name <vmname> |Remove-AzureDataDisk -lun <lun#> -deletevhd | Update-AzureVM
It will spin for a couple of minutes, but it will give you a success/failure output at the end.
This command just does it, and doesn't give you any feedback about which drive was removed. I would recommend tossing in a get-azuredatadisk first just to be sure of what you deleted.
Get-AzureVM -ServiceName <servicename> -name <vmname> | Get-AzureDataDisk
This is related to Windows Azure: Delete disk attached to non-existent VM. Cross-posting my answer here:
I was unable to use the (2016) web portal to delete orphaned disks in my (classic) storage account. Here is a detailed walk-through for deleteing these orphaned disks with PowerShell.
PowerShell
Download and install PowerShell if you haven't already. (Install and configure Azure PowerShell.) Initial steps from this doclink:
Check that the Azure PowerShell module is available after installing:
Get-Module –ListAvailable
If the Azure PowerShell module is not listed, you may need to import it:
Import-Module Azure
Login to Azure Resource Manager:
Login-AzureRmAccount
AzurePublishSettingsFile
Retreive your PublishSettingsFile.
Get-AzurePublishSettingsFile
Get-AzurePublishSettingsFile launches manage.windowsazure.com and prompts you to download an XML file that you can be saved anywhere.
Reference: Get-AzurePublishSettingsFile Documentation
Import-AzurePublishSettingsFile and specify the path to the file just saved.
Import-AzurePublishSettingsFile -PublishSettingsFile '<your file path>'
Show and Remove Disks
Show current disks. (Reference: Azure Storage Cmdlets)
Get-AzureDisk
Quickly remove all disks. (Credit to Mike's answer)
get-azuredisk | Remove-AzureDisk
Or remove disks by name. (Credit to Remove-AzureDisk Documentation)
Remove-AzureDisk -DiskName disk-name-000000000000000000 -DeleteVHD