I have found azure slot swapping via powershell seems to be unrealiable (I imagine it is giving an error response that I can't see or is silently failing but claiming success). The slots being swapped are between two non production slots as shown in the script. About 10% of the time it seems to succeed. Im not sure why it succeeds or fails, hopefully someone can shed some light on what I am doing wrong here.
I have a script I have made that runs on a build job on Teamcity and the script is as follows:
param ([string]$publishFilePath = "%system.teamcity.build.checkoutDir%\3.
deployment\Fu.publishsettings")
Import-AzurePublishSettingsFile $publishFilePath;
Select-AzureSubscription "Visual Studio Professional with MSDN";
Set-AzureSubscription -SubscriptionName "Visual Studio Professional with MSDN";
Switch-AzureWebsiteSlot -Name FuWebsite -Slot1 Build-Automation -Slot2 Staging -Force -Verbose
Switch-AzureWebsiteSlot -Name FuServices -Slot1 Build-Automation -Slot2 Staging -Force -Verbose
The only logs I get are:
[10:20:12][Step 5/5] VERBOSE: Performing the operation "Swapping website
production slot ..." on
[10:20:12][Step 5/5] target "FuWebsite".
[10:21:16][Step 5/5] VERBOSE: Performing the operation "Swapping website production slot ..." on
[10:21:16][Step 5/5] target "FuMeServices".
[10:22:19][Step 5/5]
[10:22:19][Step 5/5]
[10:22:19][Step 5/5] Process exited with code 0
About 10% of the time it seems to succeed. Im not sure why it succeeds or fails
If you not sure whether it succeed or fail. I would suggest you test below code with -Debug mode.
Switch-AzureWebsiteSlot -Name FuWebsite -Slot1 Build-Automation -Slot2 Staging -Force -Verbose -Debug
Here is the result I get on my side:
The detailed information will help you to find out the solution.
In addtion, if you execute the swap command, however the site does not change. Please try to clean IE sessions and cookies then try again. Or use KUDU to see the original file is changed or not.
Related
I have been battling with an issue for day now, Anytime i try to deploy from azure pipeline, i get this error:
Failed to create an app in Azure Active Directory. Error: The directory object quota limit for the Principal has been exceeded. Please ask your administrator to increase the quota limit or delete objects to reduce the used quota.
came across a resource on stackoverflow from:
Can't create new Service Principals in Azure despite being under quota
and followed the guide in the resource, but still didnt work.
Get-AzureADDeletedApplication -all 1 | ForEach-Object { Remove-AzureADdeletedApplication -ObjectId $_.ObjectId }
this is the error i get running the above command :
Get-AzureADDeletedApplication: The term 'Get-AzureADDeletedApplication' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Please note the command was run in powershell knowing it is a powershell command. Also, if there is a cli command to use to clear this, that would be really appreciated.
I would be gad if anyone can help cause this is frustrating and i am behind time.
Thanks guys
I tried in my environment and got similar error when I run the same commands:
Get-AzureADDeletedApplication
This error occurs due to that you have not install azureAD or install azureADPreview
Install the module
install-module AzureAD or install-module AzureADPreview
Connect with your azure active directory by following commands with your credentials.
Connect-AzureAD
When I connected with azure ad i can list all the DeletedazureADApplication.
First I tried to delete the particular AD application it is successfully deleted.
Remove-AzureADdeletedApplication -ObjectId 00000000-0000-0000-0000-000000000000
Later I tried to delete all the application with following commands and got successfully deleted the azureADdeletedapplication.
Get-AzureADDeletedApplication -all 1 | ForEach-Object { Remove-AzureADdeletedApplication -ObjectId $_.ObjectId }
Reference:
https://learn.microsoft.com/en-us/powershell/module/azuread/get-azureaddeletedapplication?view=azureadps-2.0
My (dotNET) application is built (using a Windows Hosted agent), from a build pipeline, and in the subsequent Release pipeline, I provision a 16GB-Win2016 VM (enabling RDP, HTTP, HTTPS, WinRM and SSH), into which I RDP manually (there is a Manual Intervention task here), and configure WinRM (following this article: https://learn.microsoft.com/en-us/azure/marketplace/cloud-partner-portal/virtual-machine/cpp-configure-winrm-after-vm-creation#configure-vm-to-enable-winrm). Everything is fine until here. The next task is a Azure File Copy task, which essentially copies the Build artifacts (from $(System.DefaultWorkingDirectory)) and pastes into a directory I specify. Works like a charm. The next task I have is to create a VHD of this whole VM (essentially after the copying is done).
I know I can manually RDP into the VM (again) and sysprep (with oobe/generalize/shutdown), then maybe go back to the Azure Portal and Disk Export the OS Disk (specifying the SAS URL expiration time at whatever (36000 per the article)) BUT can this all be automated?
So, long story short - I'd like to know if sysprep oobe/generalize/shutdown can be performed remotely preferably over a PS task. I understand the other part of it (exporting the disk and all) can be, but if sysprep can be done remotely nothing like it.
I tried this and got what I wanted:
$sysprep= 'C:\Windows\System32\Sysprep\Sysprep.exe'
$arg1 = '/generalize'
$arg2 = '/oobe'
$arg3 = '/shutdown'
$arg4 = '/quiet'
& $sysprep $arg1 $arg2 $arg3 $arg4 -Wait
Make sure you do NOT use Azure custom script extension to run sysprep.
Azure scripts run under the LocalSystem user context: source
Custom Script Extension will run under the LocalSystem Account
This is problematic because sysprep does NOT support running under a system user context: source
Sysprep cannot be run under the context of a System account. Running Sysprep under the context of System account by using Task Scheduler or PSExec, for example, is not supported.
Providing this so that people avoid my mistake :)
So, you dont have to configure winrm manually, you can script it\configure it while provisioning the vm. and if\when winrm is working you can just use powershell remoting to issue a command against the vm with:
Invoke-Command -ComputerName dnsname\ipaddress_goes_hehe
-ScriptBlock { sysprep /shutdown /generalise}
https://github.com/Azure/azure-quickstart-templates/tree/master/201-vm-winrm-windows
You can implement this using an Azure custom script extension. There is a github project:
https://github.com/jlongo62/AzureVMToImage containing powershell scripts to image a VM. These scripts were built to preserve VM when creating an image, instead of destroying the original VM. The scripts can be called from Azure Devops. There is no need to authenticate against the VM.
The meat of what you need is:
1- create a storageaccount blob containing the following script (the -Wait is very important):
Start-Process -FilePath C:\Windows\System32\Sysprep\Sysprep.exe -ArgumentList '/generalize /oobe /quiet /quit' -Wait
2 - invoke it on the VM:
$response = Set-AzureRmVMCustomScriptExtension `
-ResourceGroupName $vm.ResourceGroupName `
-VMName $vm.Name `
-Location $vm.Location `
-Name $ExtensionName `
-FileUri $blobUri `
-Run $FileName
Problem: When I run a Powershell runbook with an 'Invoke-AzureRmVMRunCommand' on an Azure Windows VM, and I have to STOP the runbook because of an error in the invoked command (and it idles forever), all new repetitions of the runbook fail with "Run command extension execution is in progress. Please wait for completion before invoking a run command.".
This is the runbook statement to have a PS script running on the VM:
Invoke-AzureRmVMRunCommand -ResourceGroupName $objVM.ResourceGroupName -Name $objVM.Name -CommandId 'RunPowerShellScript' -ScriptPath $strRemoteScriptFileNameTmp -Parameter $hshParams
The PS code in '$strRemoteScriptFileNameTmp' has this statement in it, which makes the runbook idling, ,i.e. need to be fixed:
Invoke-Expression -Command "$strRunTimeEnv $strExecPath $strExecParaString"
The -Command then looks as this; it shall install that ODBC driver to the VM, and works when executed with the PS CLI of the VM (RDP'd):
msiexec.exe /quiet /passive /qn /norestart /l* D:\msodbcsql_13.0_x64.log /package D:\UpdateODBC\Application\Live\msodbcsql_13.0_x64.msi IACCEPTMSODBCSQLLICENSETERMS=YES ADDLOCAL=ALL
Question: I know there is a timeout of 90 minutes for that (orphaned) command of the runbook. But, where is this idling, on the VM or the Automation Account? And, how can I kill it? It seems ridiculous to wait for 90 minutes before a new attempt to run the runbook can be made.
(I am not exactly get into a productive workflow here the way Msft have set this up... And yes, I read the posts on this topic already, and also the Msft docs which really need proof-reading by an English speaker, btw.)
To conclude this I just like to share what I was given by MSDN in their answer:
"...Invoke-AzureRmVMRunCommand is actually using a REST command to send a powershell script to the VM..."
"There are restrictions on what can be done via this method:
One script at a time can run.
You can't cancel a running script.
The maximum time a script can run is 90 minutes. After that, it will time out.
"
See:
[https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command#restrictions][1]
Best!
We have a build pipeline that includes an Azure File Copy task which copies some files from our build output to an Azure VM.
Every day now for at least a week this task has been failing with the following error:
##[error]Failed to enable copy prerequisites. Multiple VMExtensions per handler not supported for OS type 'Windows'. VMExtension
'WinRMCustomScriptExtension' with handler
'Microsoft.Compute.CustomScriptExtension' already added or specified
in input.
We have had this issue before a few times, however, the problem has, up until now seamed to corrected itself without any changes by us. This time however, it does not look like the problem is going to resolve itself without some changes or intevention.
Can you help?
Could you please provide some more information?
Which version of Copy Files are you using?
Are you using Classic or Azure Pipelines?
Which agent pool are you using?
Can you post the yaml of the Task here like this:
steps:
- task: CopyFiles#2
displayName: 'Copy Files to: 123'
inputs:
TargetFolder: /output
Azure File Copy task might fail to remove a custom extension after finishing using it. You can refer to an issue reported here.
You can try using the newest version of task Azure File Copy. Or try running below scripts to uninstall the extension before using this task as suggested in the issue thread above..
$ExtensionName = Get-AzureRmVMExtension -ResourceGroupName $VM.ResourceGroupName -VMName $VM.Name -Name WinRMCustomScriptExtension
Remove-AzureRmVMCustomScriptExtension -ResourceGroupName $VM.ResourceGroupName -VmName $VM.Name -Name $ExtensionName
When releasing the build in VSO, I would like to release it in a webapp staging slot. I'm using NewRelic, so I have to stop the staging environment, and set AlwaysOn option to false, before deployment, then put it on and start after deployment.
This is what I'm doing using Azure CLI task before the deployment task :
call azure webapp config set --slot staging Default-Web-WestEurope instanceName --alwayson false
call azure webapp stop --slot staging Default-Web-WestEurope instanceName
It works well when I launch these commands on Azure CLI on my own desktop. But when I put this script on Azure CLI Task on VSO, it works... but on the production slot.
It's very annoying because it put the production down.
Do you know how to update WebApp slot configuration in VSO continuous integration ?
According to your description, I tested it on my side and I could reproduce this issue. You could add -vv option as follows to see more verbose output.
azure webapp stop --slot <slot name> <resource-group-name> <your-webapp-name> -vv
Here is the build log of Azure CLI task from my VSO:
Note: Since Azure CLI task is in preview. For a workaround, you could leverage Azure Powershell task to stop/start your web app slot and configure the AlwaysOn option as following steps：
1. Add the AZURE Powsershell task
2. Add the following powershell script and push it to your source repository
1) Stop web app slot by using Stop-AzureRmWebAppSlot
stop-azurermwebappslot -name "<webapp-name>" -slot "<webapp-slot-name>" -resourcegroupname "<resourcegroup-name>"
2) Configure AlwaysOn by using Set-AzureRmResource
Set-AzureRmResource -resourcename "<webapp-name>\slots\<webapp-slot-name>/web" -ResourceGroupName "<resourcegroup-name>" -ResourceType "Microsoft.Web/sites/config" -ApiVersion 2015-08-01 -propertyobject #{alwaysOn = $false;} -v -force
3. Configure your task
Then we could see the following build log:
Additionally, I found there is a similar issue about the options to stop/start web app during Azure Web App deployment, you could refer to it.