change the value of instances count programmatically in azure - azure

I downloaded AutoScale from
http://blog.maartenballiauw.be/post/2011/03/21/Windows-Azure-and-scaling-how-(NET).aspx
and followed the instructions there.
I added it as reference to my existing azure project. But I am not sure what exactly I should pass as the user defined parameters for the 6 parameters required for auto scale.
I want to only change the instance count of my worker role depending on the number of documents to be processed.

Those parameters are all from the management API and the Silverlight Management UI
There are several more samples/tools for the Management API available - e.g. http://archive.msdn.microsoft.com/azurecmdlets/Wiki/View.aspx?title=Getting%20Started&version=1
There's also a commercial third party service available to assist - see paraleap.com
Maarten's tool has parameters:
Console.WriteLine(" AutoScale.exe <certificatefile> <subscriptionid> <servicename> <rolename> <slot> <instancecount>");
To generate the certificate file, see the instructions from that cmdlet article or see the instructions in http://blogs.msdn.com/b/avkashchauhan/archive/2010/12/30/handling-issue-csmanage-cannot-establish-secure-connection-to-management-core-windows-net.aspx
The subscription ID is available via the silverlight azure management UI
the ServiceName and RoleName are what you choose when you create the service in the UI and when you create the role in code
the Slot is "Production" or "Staging"
the instanceCount is how many instances you want to run

Related

Windows Virtual Desktop: Automatically start and deallocate dedicated VM

As far as I understand, Windows Virtual Desktop's host pools can be configured in a pooled (assign a user to a VM with free resources) or personal (dedicated VM per user) mode.
I have some users with special needs (available applications, configuration and VM resources) and unpredictable usage times. Would it be possible to assign specific machines to them and tie their lifecycle to the user login? What I'd like to achieve is to shutdown and deallocate the VM if the user logged out or shutdown the VM, and automatically start it (accepting some initial delay) when logging in, to only pay for the VMs when they are actually needed.
Start/Stop VMs during off-hours
It starts or stops machines on user-defined schedules, provides insights through Azure Monitor logs, and sends optional emails by using action groups. The feature can be enabled on both Azure Resource Manager and classic VMs for most scenarios.
This feature uses Start-AzVm cmdlet to start VMs. It uses Stop-AzVM for stopping VMs.
Prerequisites
The runbooks for the Start/Stop VMs during off hours feature work with an Azure Run As account. The Run As account is the preferred authentication method because it uses certificate authentication instead of a password that might expire or change frequently.
An Azure Monitor Log Analytics workspace that stores the runbook job logs and job stream results in a workspace to query and analyze. The Automation account and Log Analytics workspace need to be in the same subscription and supported region. The workspace needs to already exist, you cannot create a new workspace during deployment of this feature.
Recommended: Use a separate Automation account for working
with VMs enabled for the Start/Stop VMs during off-hours feature.
Azure module versions are frequently upgraded, and their parameters
might change. The feature isn't upgraded on the same cadence and it
might not work with newer versions of the cmdlets that it uses. Before
importing the updated modules into your production Automation
account(s), we recommend you import them into a test Automation
account to verify there aren't any compatibility issues.
Permissions
You must have certain permissions to enable VMs for the Start/Stop VMs during off-hours feature. The permissions are different depending on whether the feature uses a pre-created Automation account and Log Analytics workspace or creates a new account and workspace.
You don't need to configure permissions if you're a Contributor on the subscription and a Global Administrator in your Azure Active Directory (AD) tenant. If you don't have these rights or need to configure a custom role, make sure that you have the permissions described below.
Runbooks
The following link lists the runbooks that the feature deploys to your Automation account. Do NOT make changes to the runbook code. Instead, write your own runbook for new functionality.
Don't directly run any runbook with child appended to its name.
All parent runbooks include the WhatIf parameter. When set to True, the parameter supports detailing the exact behavior the runbook takes when run without the parameter and validates that the correct VMs are targeted. A runbook only performs its defined actions when the WhatIf parameter is set to False.
Main default runbooks:
ScheduledStartStop_Parent
SequencedStartStop_Parent
Variables (used by Runbooks)
The following table lists the variables created in your Automation account. Only modify variables prefixed with External. Modifying variables prefixed with Internal causes undesirable effects.
Main variables to use with your Runbooks:
External_Start_ResourceGroupNames: Comma-separated list of one or more resource groups that are targeted for start actions.
External_Stop_ResourceGroupNames: Comma-separated list of one or more resource groups that are targeted for stop actions.
External_ExcludeVMNames: Comma-separated list of VM names to exclude, limited to 140 VMs. If you add more than 140 VMs to the list, VMs specified for exclusion might be inadvertently started or stopped.
Schedules
Don't enable all schedules, because doing so might create overlapping schedule actions. It's best to determine which optimizations you want to do and modify them accordingly.
Scheduled_StopVM: Runs the ScheduledStopStart_Parent runbook with a parameter of Stop every day at the specified time. Automatically stops all VMs that meet the rules defined by variable assets. Enable the related schedule Scheduled-StartVM.
Scheduled_StartVM: Runs the ScheduledStopStart_Parent runbook with a parameter value of Start every day at the specified time. Automatically starts all VMs that meet the rules defined by variable assets. Enable the related schedule Scheduled-StopVM.
Sequenced-StopVM: Runs the Sequenced_StopStop_Parent runbook with a parameter value of Stop every Friday at the specified time. Sequentially (ascending) stops all VMs with a tag of SequenceStop defined by the appropriate variables. For more information on tag values and asset variables, see Runbooks. Enable the related schedule, Sequenced-StartVM.
Sequenced-StartVM: Runs the SequencedStopStart_Parent runbook with a parameter value of Start every Monday at the specified time. Sequentially (descending) starts all VMs with a tag of SequenceStart defined by the appropriate variables. For more information on tag values and variable assets, see Runbooks. Enable the related schedule, Sequenced-StopVM.
How to enable and configure Start/Stop VMs during Off-hours.
Search for and select Automation Accounts.
On the Automation Accounts page, select your Automation account from the list.
From the Automation account, select Start/Stop VM under Related Resources. From here, you can click Learn more about and enable the solution. If you already have the feature deployed, you can click Manage the solution and find it in the list.
On the Start/Stop VMs during off-hours page for the selected deployment, review the summary information and then click Create.
With the resource created, the Add Solution page appears. You're prompted to configure the feature before you can import it into your Automation account.
On the Add Solution page, select Workspace. Select an existing Log Analytics workspace from the list. If there isn't an Automation account in the same supported region as the workspace, you can create a new Automation account in the next step.
On the Add Solution page if there isn't an Automation account available in the supported region as the workspace, select Automation account. You can create a new Automation account to associate with it by selecting Create an Automation account, and on the Add Automation account page, provide the the name of the Automation account in the Name field.
All other options are automatically populated, based on the Log Analytics workspace selected. You can't modify these options. An Azure Run As account is the default authentication method for the runbooks included with the feature.
After you click OK, the configuration options are validated and the Automation account is created. You can track its progress under Notifications from the menu.
On the Add Solution page, select Configure parameters. The Parameters page appears.
Specify a value for the Target ResourceGroup Names field. The field defines group names that contain VMs for the feature to manage. You can enter more than one name and separate the names using commas (values are not case-sensitive). Using a wildcard is supported if you want to target VMs in all resource groups in the subscription. The values are stored in the External_Start_ResourceGroupNames and External_Stop_ResourceGroupNames variables.
The default value for Target ResourceGroup Names is a *. This setting
targets all VMs in a subscription. If you don't want the feature to
target all the VMs in your subscription, you must provide a list of
resource group names before selecting a schedule.
Specify a value for the VM Exclude List (string) field. This value is the name of one or more virtual machines from the target resource group. You can enter more than one name and separate the names using commas (values are not case-sensitive). Using a wildcard is supported. This value is stored in the External_ExcludeVMNames variable.
Use the Schedule field to select a schedule for VM management by the feature. Select a start date and time for your schedule to create a recurring daily schedule starting at the chosen time. Selecting a different region is not available. To configure the schedule to your specific time zone after configuring the feature, see Modify the startup and shutdown schedules.
To receive email notifications from an action group, accept the default value of Yes in the Email notifications field, and provide a valid email address. If you select No but decide at a later date that you want to receive email notifications, you can update the action group that is created with valid email addresses separated by commas. The following alert rules are created in the subscription:
AutoStop_VM_Child
Scheduled_StartStop_Parent
Sequenced_StartStop_Parent
After you have configured the initial settings required for the feature, click OK to close the Parameters page.
Click Create. After all settings are validated, the feature deploys to your subscription. This process can take several seconds to finish, and you can track its progress under Notifications from the menu.
Scenario 1: Start/Stop VMs on a schedule
This scenario is the default configuration when you first deploy Start/Stop VMs during off-hours. For example, you can configure the feature to stop all VMs across a subscription when you leave work in the evening, and start them in the morning when you are back in the office. When you configure the schedules Scheduled-StartVM and Scheduled-StopVM during deployment, they start and stop targeted VMs.
Configuring the feature to just stop VMs is supported. See Modify the startup and shutdown schedules to learn how to configure a custom schedule.
The time zone used by the feature is your current time zone when you
configure the schedule time parameter. However, Azure Automation
stores it in UTC format in Azure Automation. You don't have to do any
time zone conversion, as this is handled during machine deployment.
To control the VMs that are in scope, configure the variables: External_Start_ResourceGroupNames, External_Stop_ResourceGroupNames, and External_ExcludeVMNames.
You can enable either targeting the action against a subscription and resource group, or targeting a specific list of VMs, but not both.
Target the start and stop action by VM list
Run the ScheduledStartStop_Parent runbook with ACTION set to start.
Add a comma-separated list of VMs (without spaces) in the VMList parameter field. An example list is vm1,vm2,vm3.
Set the WHATIF parameter field to True to preview your changes.
Configure the External_ExcludeVMNames variable with a comma-separated list of VMs (VM1,VM2,VM3), without spaces between comma-separated values.
This scenario does not honor the External_Start_ResourceGroupNames and External_Stop_ResourceGroupnames variables. For this scenario, you need to create your own Automation schedule. For details, see Schedule a runbook in Azure Automation.
Scenario 2: Start/Stop VMs in sequence by using tags
Target the start and stop actions against a subscription and resource group
Add a sequencestart and a sequencestop tag with positive integer values to VMs that are targeted in External_Start_ResourceGroupNames and External_Stop_ResourceGroupNames variables. The start and stop actions are performed in ascending order. To learn how to tag a VM, see Tag a Windows virtual machine in Azure and Tag a Linux virtual machine in Azure.
Modify the schedules Sequenced-StartVM and Sequenced-StopVM to the date and time that meet your requirements and enable the schedule.
Run the SequencedStartStop_Parent runbook with ACTION set to start and WHATIF set to True to preview your changes.
Preview the action and make any necessary changes before implementing against production VMs. When ready, manually execute the runbook with the parameter set to False, or let the Automation schedules Sequenced-StartVM and Sequenced-StopVM run automatically following your prescribed schedule.
Scenario 3: Start or stop automatically based on CPU utilization
Start/Stop VMs during off-hours can help manage the cost of running Azure Resource Manager and classic VMs in your subscription by evaluating machines that aren't used during non-peak periods, such as after hours, and automatically shutting them down if processor utilization is less than a specified percentage.
By default, the feature is pre-configured to evaluate the percentage CPU metric to see if average utilization is 5 percent or less. This scenario is controlled by the following variables and can be modified if the default values don't meet your requirements:
External_AutoStop_MetricName
External_AutoStop_Threshold
External_AutoStop_TimeAggregationOperator
External_AutoStop_TimeWindow
External_AutoStop_Frequency
External_AutoStop_Severity
You can enable and target the action against a subscription and resource group, or target a specific list of VMs.
When you run the AutoStop_CreateAlert_Parent runbook, it verifies that the targeted subscription, resource group(s), and VMs exist. If the VMs exist, the runbook calls the AutoStop_CreateAlert_Child runbook for each VM verified by the parent runbook. This child runbook:
Creates a metric alert rule for each verified VM.
Triggers the AutoStop_VM_Child runbook for a particular VM if the CPU drops below the configured threshold for the specified time interval.
Attempts to stop the VM.
Target the autostop action against all VMs in a subscription
Ensure that the External_Stop_ResourceGroupNames variable is empty or set to * (wildcard).
[Optional] If you want to exclude some VMs from the autostop action, you can add a comma-separated list of VM names to the External_ExcludeVMNames variable.
Enable the Schedule_AutoStop_CreateAlert_Parent schedule to run to create the required Stop VM metric alert rules for all of the VMs in your subscription. Running this type of schedule lets you create new metric alert rules as new VMs are added to the subscription.
Target the autostop action against all VMs in a resource group or multiple resource groups
Add a comma-separated list of resource group names to the External_Stop_ResourceGroupNames variable.
If you want to exclude some of the VMs from the autostop, you can add a comma-separated list of VM names to the External_ExcludeVMNames variable.
Enable the Schedule_AutoStop_CreateAlert_Parent schedule to run to create the required Stop VM metric alert rules for all of the VMs in your resource groups. Running this operation on a schedule allows you to create new metric alert rules as new VMs are added to the resource group(s).
Target the autostop action to a list of VMs
Create a new schedule and link it to the AutoStop_CreateAlert_Parent runbook, adding a comma-separated list of VM names to the VMList parameter.
Optionally, if you want to exclude some VMs from the autostop action, you can add a comma-separated list of VM names (without spaces) to the External_ExcludeVMNames variable.
Configure email notifications
In the Azure portal, click on Alerts under Monitoring, then Manage actions. On the Manage actions page, make sure you're on the Action groups tab. Select the action group called StartStop_VM_Notification.
On the StartStop_VM_Notification page, the Basics section will be filled in for you and can't be edited, except for the Display name field. Edit the name, or accept the suggested name. In the Notifications section, click the pencil icon to edit the action details. This opens the Email/SMS message/Push/Voice pane. Update the email address and click OK to save your changes.
Add a VM
There are two ways to ensure that a VM is included when the feature runs:
Each of the parent runbooks of the feature has a VMList parameter. You can pass a comma-separated list of VM names (without spaces) to this parameter when scheduling the appropriate parent runbook for your situation, and these VMs will be included when the feature runs.
To select multiple VMs, set External_Start_ResourceGroupNames and External_Stop_ResourceGroupNames with the resource group names that contain the VMs you want to start or stop. You can also set the variables to a value of * to have the feature run against all resource groups in the subscription.
Exclude a VM
To exclude a VM from Stop/start VMs during off-hours, you can add its name to the External_ExcludeVMNames variable. This variable is a comma-separated list of specific VMs (without spaces) to exclude from the feature. This list is limited to 140 VMs. If you add more than 140 VMs to this list, VMs that are set to be excluded might be inadvertently started or stopped.
Modify the startup and shutdown schedules
Managing the startup and shutdown schedules in this feature follows the same steps as outlined in Schedule a runbook in Azure Automation. Separate schedules are required to start and stop VMs.
Configuring the feature to just stop VMs at a certain time is supported. In this scenario you just create a stop schedule and no corresponding start schedule.
Ensure that you've added the resource groups for the VMs to shut down in the External_Stop_ResourceGroupNames variable.
Create your own schedule for the time when you want to shut down the VMs.
Navigate to the ScheduledStartStop_Parent runbook and click Schedule. This allows you to select the schedule you created in the preceding step.
Select Parameters and run settings and set the ACTION field to Stop.
Select OK to save your changes.
I believe an Automation Runbook with Start/Stop following a specific schedule doesn't fit the requirements of "unpredictable usage times". Using CPU usage would work when logging off (although even if implemented properly, there could be a small acceptable delay). For log-on I think you have a Catch-22. From what I understand a user is generally tied to a WVD pool and if that pool isn't available, the user can't login. So turning on the machine at log on wouldn't work as for that user to even be able to login would require the machine to be turned on prior.
Assuming your users are not tech savvy and giving them access to an Start/Stop Runbook might not be practical, the only other option I can think of is having an Automation Runbook triggered by a custom callback using webhooks. See Azure Automation Webhooks. With a very simple web interface and just two options provided, (Start WVD, Stop WVD) users can trigger the actions themselves.
If you want explore other options like Azure Logic Apps, you get even more event listeners. Some examples: Users could send an email with specific keyword to an inbox that the Logic App is actively checking, which would then trigger the desired action.
I don't know if you're using Log Analytics for collecting Azure Activity Logs but if yes, a mix with the options above could do the trick.
Use Logic App to listen for an event or Runbooks with webhooks, to give users the flexibility to turn on the machine when they need.
Use Logic App and Log Analytics, to listen for a log out event from the machine or to monitor for CPU utilisation over a period of time and act on the result. See Azure Automation Solution for VM Management
I have to implement something similar myself and these are the options I have in mind. I wish I could provide more concrete examples with actual use cases. Will update this in the future when I get there.
EDIT: Did some digging and stumbled upon this repo that provides more info, with screenshots and also the scripts when compared with the official Azure documentation that seem very vague.
Also, since I mentioned Log Analytics earlier, here's a Log Analytics query you can use to find start/end connections in the past 24hrs.
WVDConnections
| where TimeGenerated > ago(24h)
| where State == "Connected"
| project CorrelationId , UserName , StartTime=TimeGenerated, SessionHostName
| join (WVDConnections
| where State == "Completed"
| project EndTime=TimeGenerated, CorrelationId)
on CorrelationId
| parse SessionHostName with Host "domain" //If applicable use parser to remove part of a value to clean it up.
| project StartTime, EndTime, UserName, Host
| sort by StartTime desc

Azure PowerShell Scripts - Restrict Get-AzureRmWebAppPublishingProfile to Filezilla

I'm trying to come up with a combination of Custom Role and PowerShell script that will constrain an AD members capabilities to the following (for a particular web app):
1) Require an interactive login to an AD account
2) Perform a download of a Publish Profile, but only in Filezilla format
The purpose is to provide a "deployer" role with the ability to upload code changes, but not see connection strings, which are visible in Web Deploy publish settings.
I see the necessary level of control in Powershell for downloading only the FileZilla3 FTP Publishing data, and I got that to work, example:
Get-AzureRmWebAppPublishingProfile -Name test-app -ResourceGroupName test_Group -Format FileZilla3 -OutputFile S:\test.xml
I understand the pattern for creating a Custom Role, and for adding actions to it. These look like the actions I might need:
Microsoft.Web/sites/publishxml/Action
microsoft.web/sites/publishxml/read
However, I don't see another level of detail within those actions for constraining the action to only Filezilla3 format.
Question: is there a way to create a Custom Role specification that would allow an AD member to download publish settings, but only in FileZilla3 format?
From the official docs, there is no ways to create a Custom Role you want. For the details, please read here.

Update WadCfg "only" of existing Azure Service Fabric cluster?

I want to monitor Perfomance metrics of a existing Service Fabric Cluster.
Here is the link of Performance metrics -
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-diagnostics-event-generation-perf
I went through this Microsoft documentation -
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-diagnostics-perf-wad
My problem is, The ARM template I downloaded during Service Fabric creation time is quite big and contains lot of params and I don't have the template-params file. I think it is possible to build the params file but it will be time consuming.
Is it possible to download template and template-params file of
existing service fabric cluster ?
If no, Is it possible to just update the "WadCfg" section to add new
performance counters ?
Your can export your entire resource group with all definitions and parameters, there you can find all parameters(as default parameters) for the resources deployed in the resource group. I've never done for SF cluster, but a quick look to an existing resource group I have I could see the cluster definition included.
This link explain how: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-export-template
In Summary:
Find the resource group where your cluster is deployed
Open the resource group and navigate to 'Automation Scripts'
Click 'Download' on top bar
Open the ARM template with all definitions
Make the modifications and save
Publish the updates
1:
2:
You could also add it to a library and deploy from there, as guided in the link above.
From the docs: Not all resource types support the export template function. To resolve this issue, manually add the missing resources back into your template.
To be honest, I've never deployed this way other than test environments, so I am not sure if it is safe for production.

How can I programatically (C#) read the autoscale settings for a WebApp?

I'm trying to build a small program to change the autoscale settings for our Azure WebApps, using the Microsoft.WindowsAzure.Management.Monitoring and Microsoft.WindowsAzure.Management.WebSites NuGet packages.
I have been roughly following the guide here.
However, we are interested in scaling WebApps / App Services rather than Cloud Services, so I am trying to use the same code to read the autoscale settings but providing a resource ID for our WebApp. I have already got the credentials required for making a connection (using a browser window popup for Active Directory authentication, but I understand we can use X.509 management certificates for non-interactive programs).
This is the request I'm trying to make. Credentials already established, and an exception is thrown earlier if they're not valid.
AutoscaleClient autoscaleClient = new AutoscaleClient(credentials);
var resourceId = AutoscaleResourceIdBuilder.BuildWebSiteResourceId(webspaceName: WebSpaceNames.NorthEuropeWebSpace, serverFarmName: "Default2");
AutoscaleSettingGetResponse get = autoscaleClient.Settings.Get(resourceId); // exception here
The WebApp (let's call it "MyWebApp") is part of an App Service Plan called "Default2" (Standard: 1 small), in a Resource Group called "WebDevResources", in the North Europe region. I expect that my problem is that I am using the wrong names to build the resourceId in the code - the naming conventions in the library don't map well onto what I can see in the Azure Portal.
I'm assuming that BuildWebSiteResourceId is the correct method to call, see MSDN documentation here.
However the two parameters it takes are webspaceName and serverFarmName, neither of which match anything in the Azure portal (or Google). I found another example which seemed to be using the WebApp's geo region for webSpaceName, so I've used the predefined value for North Europe where our app is hosted.
While trying to find the correct value for serverFarmName in the Azure Portal, I found the Resource ID for the App Service Plan, which looks like this:
/subscriptions/{subscription-guid}/resourceGroups/WebDevResources/providers/Microsoft.Web/serverfarms/Default2
That resource ID isn't valid for the call I'm trying to make, but it does support the idea that a 'serverfarm' is the same as an App Service Plan.
When I run the code, regardless of whether the resourceId parameters seem to be correct or garbage, I get this error response:
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
{"Code":"SettingNotFound","Message":"Could not find the autoscale settings."}
</string>
So, how can I construct the correct resource ID for my WebApp or App Service Plan? Or alternatively, is there a different tree I should be barking up to programatially manage WebApp scaling?
Update:
The solution below got the info I wanted. I also found the Azure resource explorer at resources.azure.com extremely useful to browse existing resources and find the correct names. For example, the name for my autoscale settings is actually "Default2-WebDevResources", i.e. "{AppServicePlan}-{ResourceGroup}" which I wouldn't have expected.
There is a preview service https://resources.azure.com/ where you can inspect all your resources easily. If you search for autoscale in the UI you will easily find the settings for your resource. It will also show you how to call the relevant REST Api endpoint to read or update that resorce.
It's a great tool for revealing a lot of details for your deployed resources and it will actually give you an ARM template stub for the resource you are looking at.
And to answer your question, you could programmatically call the REST API from a client with updated settings for autoscale. The REST API is one way of doing this, the SDK another and PowerShell a third.
The guide which you're following is based on the Azure Service Management model, aka Classic mode, which is deprecated and only exists mainly for backward compatibility support.
You should use the latest
Microsoft.Azure.Insights nuget package for getting the autoscale settings.
Sample code using the nuget above is as below:
using Microsoft.Azure.Management.Insights;
using Microsoft.Rest;
//... Get necessary values for the required parameters
var client = new InsightsManagementClient(new TokenCredentials(token));
client.AutoscaleSettings.Get(resourceGroupName, autoScaleSettingName);
Besides, the autoscalesettings is a resource under the "Microsoft.Insights" provider and not under the "Microsoft.Web" provider, which explains why you are not able to find it with your serverfarm resourceId.
See the REST API Reference below for getting the autoscale settings.
GET
https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/microsoft.insights/autoscaleSettings/{autoscale-setting-name}?api-version={api-version}

Run an arbitrary Azure provider operation

In the Azure CLI resource manager, we can list providers and their operations.
azure provider list
azure provider operations show Microsoft.Web/sites/*
How do we run one of the listed operations. For instance, how would we run this:
Operation : Microsoft.Web/sites/sourcecontrols/web/Read
OperationName : Get Web App's source control configuration
ProviderNamespace : Microsoft Web Apps
ResourceName : Web App Source Control
Description : Get Web App's source control configuration settings.
The purpose of azure provider operations show is to display operations that are supported by the various providers so that you can use them to create custom Role Based Access Control (RBAC) roles. They are not actual commands or endpoints that can be executed.
To create a custom RBAC role, you first create a JSON file describing the role and operations allowed by the role, then pass the file to azure role create.
More details here.. https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-manage-access-azure-cli/#create-a-custom-role

Resources