Is there a way to programmatically configure Azure Cloud Shell without having to launch it and have it create a new storage account and file share (or go manually configure it to use existing resources)?
I'd like to be able to have an Azure CLI script (or Terraform) create the storage account and file share for me and have Azure Cloud Shell detect these resources and use them so when the Cloud Shell button is clicked there is not configuration needed.
This is needed whenever a new account is created or the resource group that contains the Cloud Shell storage account is deleted.
I believe currently feature to programmatically configure Cloud Shell to detect and select particular storage account and file share is not supported. So I would recommend you to raise this as a feature request in this Uservoice or feedback forum.
However, IF the actual use case and requirement is - " to access the Cloud Shell (https://shell.azure.com/) without configuration need or at least by configuring only one time per subscription (that may be done manually)", THEN this is the feature request for the same which is already raised in Uservoice or feedback forum. So if interested, I recommend you to upvote it and other features that are of interest.
In general, Azure feature or product team would check feasibility of a feature request, triage it, prioritize against existing feature backlog, add in roadmap as appropriate and would announce and/or update the related Azure document once a feature request is addressed.
Related
I have a single-tenant logic app and a workflow under it that needs a configurable input. In a multi-tenant logic app, one can define parameters through the azure portal and reference them in workflow definition (actions/ triggers). Is this not possible with a single-tenant logic app?
I am not able to find the answer in the documentation.
I know a deployment template should consult parameters file for this, however, I still have the above question specifically if I am doing stuff through the portal.
Edit 7/12
I am referring to the parameters concept explained here, and not the parameters tab of the triggers or actions. See below the parameters that we can define through the portal when working with the consumption logic app.
The answer is: not yet. Support for parameters in the designer (and therefore in the Azure Portal) is on its way, but not available yet.
In VS Code, you can create a parameters.json file.
But in the portal, there's no option (yet) to create/edit parameters.
Bec Lyons (Microsoft) demoed a version of the designer with this in it, although I can't remember if this was in the June Logic Apps Live session, or in the July Integration Down Under session.
In any case, the only currently supported way to do this is to create a parameters.json file and upload it.
You can either do this from VS Code or Azure CLI (using the preview logicapps CLI extension) OR you can FTP to your Logic App and upload it via an FTP client (e.g. FileZilla) - you can get the FTP login details by clicking the "Get Publish Profile" button in the overview of your Logic Apps Standard resource.
Once they release support for this in the Portal/Designer, I'll update this answer.
Also, worth noting that as of this date (July 2021), there are issues using parameters in Managed API Triggers - not sure yet if this is by design, or if it's a bug. Specifically the FileSystem, FTP and FTPWithSSH (SFTP) triggers.
Hope this helps. Probably not the answer you were looking for, though!
I am trying to automate VMs onboarding process for Azure Update Management. I am wondering if it possible, I didnt find solution which I can use to full onboard VM to Update Management, from A-Z. I mean I need MMA agent installation (i have script prepared, for installing mma vm extension with workspace ID and Key). Problem is that thare I didn't find a way to perform rest of the steps. Did anyone try to do this, I know that Ms give the runbook form this but I am not sure if its working as expected, link here --> https://learn.microsoft.com/en-us/azure/automation/update-management/enable-from-runbook
You can automate it by configuring UM to automatically enable for all existing and future VMs using this method - Enable Machine in the workspace
But keep in mind that using this method doesn't allow you to have the control an enterprise customer would want.
We don't have an out of the box method to configure from the VM, onboarding it to UM in an automated manner. Based on how it is designed, the only way out of the box is from the portal, or runbook as described in docs.
Programatically to work around this (and I'm thinking out loud here) you could update the saved search query - MicrosoftDefaultComputerGroup in the workspace with the UUID of the VM and that would automate onboarding it to the feature. I don't have a working example to share but I think the approach is sound and can be included in the workflow to onboard it.
I am publishing an app to the Azure Marketplace. My offer is a VM. My use case is that i need the customer to enter some values that will be used to call a script in the VM. How can i pass custom variables to the VM during launch?
According to this you can only customize them with SKU's, so this means any post deployment configurations are to be done by the customer.
What you see to need is an Azure Application Offer. That one would contain a way to customize it.
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.
I created my custom Azure Worker Role. This code is ready. What I'm trying to do is to create instances of this Azure-Worker-Role in specific Azure data-center, at the requested time. For example, I'm want to send command to Azure to create 10 instances of my Custom-Azure-Worker in West-Europe data-center - now.
It's important to pass this command also a parameter that will be the input problem to be solved by my workers.
I pretty sure that this automation task must be covered by Azure automation. Is that true? Looking for more information\directions.
Thank you!
You can use Azure Management Libraries to create and deploy your cloud services from C# code. Just create application (eg ASP.NET MVC) to manage your cloud services by sending commands and deploy it also on Azure or even keep it locally.
See this article for more details http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries
You'll want to leverage the service management API to spin up and tear down roles. It can be accessed any number of way, including directly via REST.
RE: providing a parameter to the worker role, one option is leveraging the cloud service configuration file that you provide with the cspkg. Define specifics for the role there.
Depending on the complexity or simplicity of your scenario, you may also get away with simply having a table in storage that you personally poke with desired configuration values and that the worker can read to retrieve.
The Azure Automation service should definitely be able to automate this task for you. Anything you can script via the Azure PowerShell module, can be imported as a runbook and called manually, via a third-party system, or on a schedule in Azure Automation.
Whether there is an existing runbook for the specific task you are looking to automate, I do not know. But Azure Automation has a gallery of community-contributed content for many common processes, so this may be available there.