We were originally using Start-AzureWebsite and Stop-AzureWebsite in a powershell script to start and stop web apps in Azure before publishing. In the VSO build it was using Azure Powershell, the connection type was Azure Classic. Microsoft recommended switching to Start-AzureRmWebApp and Stop-AzureRmWebApp which uses the Azure Resource Manager. We modified the Azure Powershell step in the build to have a connection type of Azure Resource Manager, and selected the correct subscription. When it calls our external script using the script path, it appears as though the authentication is not being passed on to the script, we get the error "Run Login-AzureRmAccount to login." when it tries to execute the command to start/stop the websites. How do we get the authentication to persist down to the script being called?
Not sure why the connection get lost, it should work if you dotsource the script to invoke it. However:
I would suggest to create a service principal within the AAD that is linked to your subscription and grant it access to your web app. Then you should use the existing Azure App Service Manage Task to start / stop your app:
By the way, starting / stopping / deploying a web app should be part of a Release Definition / Step - not build.
-
Turns out instead of using Connect-AzureRMAccount i needed to be using Add-AzureRmAccount, once i changed that i can now connect and start/stop App Services! Thank you for the help. – Link
Related
I am trying to wrap up my mind around this process.
I have a SQL Server in azure. This server has a Azure Active Directory Admin enable using an azure group to authenticate using MFA.
Further more, in the same blade, I have enabled the Support only Azure Active Directory Authentication for this server.
Everything works just fine, and I am able to connect to my server by using MFA as I am part of the Active directory.
Now, I am a disaster and most of the time I forget to update my database schema, and when I deploy some tests, everything explodes.
I have been looking around for an automation process to authenticate with azure DevOps and run a sql script every time my release pipeline is triggered.
I came across this documentation
https://learn.microsoft.com/en-us/powershell/module/sqlserver/invoke-sqlcmd?view=sqlserver-ps
Which seems to be just what a need as it has the --InputFile.
but I am having some problems to understand how I can authenticate my release pipeline and perform those changes using an AAD to access the DB without having to expose username and password.
If anyone can help me to understand what its the best approach here iw ill be grateful.
And please if my question is not 100% clear, just let me know and I will explain better
An alternative would be to write a script which will do all the sql queries instead of doing it in pipeline. This way we can using azure ad to authenticate.
Register the sql service to the azure ad then we can get tokens to authenticate the sql queries.
finally run the script in pipeline using command line task
Reference:
how to run script
authenticate using azure ad
I have one release pipeline where i am deploying latest/selected artifacts to one web app.
I want to release the same artifacts to multiple web app in single release pipeline.
I have two option in my mind.
Create a multiple task with each web app. (this is achievable but every time pipeline changes requires whenever there is new web app getting in picture)
using Power shell but not sure why my command is not working here . getting error as The term 'Publish-AzWebApp' is not recognized as the name of a cmdlet, Though this command is working fine in local system but not in pipeline.
Publish-AzWebApp -ResourceGroupName gggroup -Name $app -ArchivePath $(System.DefaultWorkingDirectory)/**/*.zip
this command will run in loop.
Any suggestion!!!
For option 2, Publish-AzWebApp is a step for classic deployment. However, modules for classic deployment are not supported in PowerShell task of Azure DevOps services any more.
Instead, you can use the Azure PowerShell task.
Also, you can deploy ZIP file with REST APIs then invoke the REST APIs using PowerShell.
POST https://<app_name>.scm.azurewebsites.net/api/zipdeploy
The POST request must contain the .zip file in the message body. The deployment credentials for your app are provided in the request by using HTTP BASIC authentication. Click this document for detailed information.
We have been working on setting up thebuild definition on the on Premise TFS 2015 server, however are stuck with the proxy issue that’s coming while running a build task (Azure powershell). The build task actually makes a call out to Azure to add an authenticated account to be used for Azure cmdlets, but however getting blocked by the proxy server as seen below. We need a way to pass current user credentials to the Azure Powershell cmdlets, any help would be appreciated.
Error Message
Network Access Message: The page cannot be displayed
Technical Information (for Support personnel)
Error Code: 407 Proxy Authentication Required. The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. (12209)
IP Address: some IP address
Date: 17/03/2017 09:03:58 [GMT]
Server: ..com
Source: proxy
Tried putting [System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials in the custom PowerShell script to be run as the task, however it gets blocked before entering the custom script. Basically, before running the custom script, Azure PowerShell build task tries to run Add-AzureRmAccount which makes a call out to Azure to add an authenticated account to be used for Azure cmdlets where it gets blocked by the proxy.
Finally, had to go to the basics, we switched to simple PowerShell task instead of Azure PowerShell for doing the initial handshake and passing the default credentials to the proxy.
Here's the link to the detailed workaround.
I am trying to publish to a service fabric cluster secured using Azure Active Directory from PowerShell calling Deploy-FabricApplication.ps1 as part of a TeamCity build configuration.
I have been unable to find how you provide credentials in this situation.
I did notice in Deploy-FabricApplication.ps1 that there is a SecurityToken parameter for Active Directory.
Is this what you need to pass to authenticate, and if so how can you generate the security token within PowerShell?
I have set up a user within my Azure Active Directory for TeamCity that I am hopping to authenticate as.
The token can be acquired by making use of the Active Directory Authentication Library (ADAL), specifically by calling the method AcquireToken in Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.
A good example of this being used can be seen in the code for the VSTS Service Fabric Deploy task at: https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/ServiceFabricDeploy/utilities.ps1.
There's a function in that file called Get-AadSecurityToken which shows the call to the AuthenticationContext.AcquireToken method.
You need to ensure that you have both the cluster app ID and the client app ID. Both of these are retrievable from the cluster by calling Connect-ServiceFabricCluster with the -GetMetadata switch (this is also done in the Get-AadSecurityToken function).
I'm deploying Azure app services with Git continuous deployment and using post deployment action hooks to log the deployment to a Slack channel. My action hooks are written as PowerShell scripts.
From within my PowerShell scripts how do I access Azure or Kudu environmental variables or app settings? It's clear how to do this via deploy.cmd but I'm having no luck from PowerShell.
Ideally I'd like to be able to access things like:
Azure app service name
Deployment slot name
Deployment source/target paths
App settings and/or connection strings
Ok figured this out, apparently all of the Azure environment variables available within your website app service are available to PowerShell scripts running as post deployment actions.
To get the site name within PowerShell:
$siteName = [environment]::GetEnvironmentVariable("WEBSITE_SITE_NAME");
In addition to site name there are dozens of other Azure environment variables plus your app settings and connection strings.