I tried to change the tier / SKU of my IoT Central instance. However I can't find the option to do so either in the Azure Portal or in IoT Central.
Is it possible to change the SKU of the instance or do I have to create a new instance?
You can change the pricing plan for an Azure IoT Central application via Settings - Application - Pricing. See also the FAQ. There is no UI to change the SKU in the Azure Portal.
It can also be changed through Azure CLI or ARM templates / bicep. The current valid values are ST0, ST1, ST2 for Standard 0, 1 and 2 respectively.
https://learn.microsoft.com/en-us/cli/azure/iot/central/app?view=azure-cli-latest#az-iot-central-app-update
az iot central app update -n my-first-iot-app -g MyResourceGroup --set sku.name=ST1
https://learn.microsoft.com/en-us/azure/templates/microsoft.iotcentral/iotapps?tabs=json
{
"type": "Microsoft.IoTCentral/iotApps",
"apiVersion": "2021-11-01-preview",
"name": "string",
"location": "string",
"tags": {
"tagName1": "tagValue1",
"tagName2": "tagValue2"
},
"sku": {
"name": "string"
},
"identity": {
"type": "string"
},
"properties": {
"displayName": "string",
"networkRuleSets": {
"applyToDevices": "bool",
"applyToIoTCentral": "bool",
"defaultAction": "string",
"ipRules": [
{
"filterName": "string",
"ipMask": "string"
}
]
},
"publicNetworkAccess": "string",
"subdomain": "string",
"template": "string"
}
}
Related
I'm new to Azure and newer to using ARM templates.
I've got an App Service and Service Plan supporting Windows OS that needs to be changed to Linux. From what I can tell, there is no direct modification to achieve this result, I'm going to need to delete and redeploy.
I was looking at steps for manual deletion and re-build, but I'm thinking that using ARM templates would likely be more effective. I'm researching using ARM templates but not getting much information about using them for removal/modify/replacement. I'd guess that I can download the existing ARM templates and re-deploy, but there have to be a handful of gotchas, but I don't know what to look for.
My expectation is that the ARM template would not be able to deploy the custom domain and its certificate ready to go. Also, the existing template has references to snapshots that would likely be gone after deletion, so I'd expect to have to remove those references from the template prior to re-deploy.
Any guidance I can get would be greatly appreciated!
Per
One of the workaround you can follow ;
I'm researching using ARM templates but not getting much information
about using them for removal/modify/replacement
AFAIK, There is no direct command to delete the resources through which are deployed to Azure using ARM.
Instead of that you can use Azure cli as suggested in this SO THREAD,
Because after deployment there is still you can see in the deployment logs your resource are there you can delete from the portal itself.
After remove the app service from portal you can redeploy the same with adding your modifications.
We have tried after deploy the application and then remove/delete from portal as mentioned above and then re-deploy the app service with linux environment and its work fine.
You can make it use of below template(e.g):-
template.json
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"webAppName": {
"type": "string",
"defaultValue": "AzureLinuxApp",
"metadata": {
"description": "Base name of the resource such as web app name and app service plan "
},
"minLength": 2
},
"sku": {
"type": "string",
"defaultValue": "S1",
"metadata": {
"description": "The SKU of App Service Plan "
}
},
"linuxFxVersion": {
"type": "string",
"defaultValue": "php|7.4",
"metadata": {
"description": "The Runtime stack of current web app"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"webAppPortalName": "[concat(parameters('webAppName'), '-webapp')]",
"appServicePlanName": "[concat('AppServicePlan-', parameters('webAppName'))]"
},
"resources": [
{
"type": "Microsoft.Web/serverfarms",
"apiVersion": "2020-06-01",
"name": "[variables('appServicePlanName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('sku')]"
},
"kind": "linux",
"properties": {
"reserved": true
}
},
{
"type": "Microsoft.Web/sites",
"apiVersion": "2020-06-01",
"name": "[variables('webAppPortalName')]",
"location": "[parameters('location')]",
"kind": "app",
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
],
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]",
"siteConfig": {
"linuxFxVersion": "[parameters('linuxFxVersion')]"
}
}
}
]
}
app.parameter.json
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"webAppName": {
"value": "mylinuxappp"
}
}
}
OUTPUT DETAILS FOR REFERENCE:-
To deploy webapp with custom domain and ssl certificate need to make sure that its already verified and also need to use existing keyvault for the SSL binding . Please find this arm template for more information.
Please refer the below links for get started with Azure App service using arm template with different scenarios(step by step guidance). It should be help more to understand .
MICROSOFT DOCUMENTATIONS| Azure Resource Manager templates for App Service & Quickstart: Create App Service app using an ARM template
I have two premium Service bus instances deployed manually through the azure portal. They don't have geo-recovery alias configured and the service bus instances have been operational for about a year.
Now, I'm trying automate the deployment process of these service bus instances and also add a georecovery alias resource to it as follows:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"serviceBusNamespaceName": {
"type": "string",
"metadata": {
"description": "Name of the Service Bus namespace"
}
},
"serviceBusQueueName": {
"type": "string",
"metadata": {
"description": "Name of the Queue"
}
},
"serviceBusLocation": {
"type": "string"
},
"sku": {
"type": "object",
"defaultValue": "Standard"
},
"serviceBusTopicName": {
"type": "string"
},
"serviceBusSubscriptionName": {
"type": "string"
},
"isAliasEnabled": {
"type": "bool"
},
"isQueueCreationEnabled": {
"type": "bool"
},
"aliasName": {
"type": "string"
},
"partnerNamespace": {
"type": "string"
}
},
"variables": {
"defaultSASKeyName": "RootManageSharedAccessKey",
"authRuleResourceId": "[resourceId('Microsoft.ServiceBus/namespaces/authorizationRules', parameters('serviceBusNamespaceName'), variables('defaultSASKeyName'))]",
"sbVersion": "2017-04-01"
},
"resources": [
{
"apiVersion": "2018-01-01-preview",
"name": "[parameters('serviceBusNamespaceName')]",
"type": "Microsoft.ServiceBus/Namespaces",
"location": "[parameters('serviceBusLocation')]",
"sku": {
"name": "[parameters('sku').name]",
"tier": "[parameters('sku').tier]",
"capacity": "[parameters('sku').capacity]"
},
"properties": {
"zoneRedundant": false
},
"resources": [
{
"apiVersion": "2017-04-01",
"name": "[parameters('aliasName')]",
"type": "disasterRecoveryConfigs",
"condition": "[parameters('isAliasEnabled')]",
"dependsOn": [
"[concat('Microsoft.ServiceBus/namespaces/', parameters('serviceBusNamespaceName'))]"
],
"properties": {
"partnerNamespace": "[parameters('partnerNamespace')]"
}
}
]
}
]
}
I'm using the same template to deploy the primary and secondary instances separately. Note that the disasterRecoveryConfigs resource will only be deployed when it's the primary instance.
This template successfully deploys the secondary namespace, but the primary namespace deployment fails with the following error:
Unable to freeze secondary namespace before creating pairing, this is
probably because secondary namespace is not empty.
Which is correct i.e. the secondary namespace has a couple of topics/subscriptions and queues already created. I don't want to delete them and just want to pair the primary and secondary namespaces.
How can this be done?
I had a similar issue with the Service Bus Geo-Recovery ARM Template. I read the exception closely; its state that the secondary namespace is not empty means we have to delete the topic and queue from the secondary namespace, then run the template again. It will work and create the topic and queue again based on the primary namespace.
But if you run the template a second time, you will get a different exception, which is that the secondary namespace cannot be updated (since it’s in geo-pairing). It’s strange, but by design, you cannot update the secondary namespace while it’s in Geo Pairing, and even if you remove Geo Pairing, your secondary namespace should be empty without any instances such as Topic, Queue, etc.
How to overcome this?
Lets consider, now I wanted to add the Topic or Queue in existing deployment by using the ARM template then, you will ran into the issue when your template is in the pipeline or anywhere and needs to run multiple times and update the existing primary namespace.
1. Quick Fix (one time only second time manually again you have to do the following steps)
Login to the Azure Portal
Go to the your primary Service bus Namespace
Click on the Geo-Recovery option under setting section
At the right hand side at the top find the option break pairing and
click on it.
It will break the pairing & if you not follow this step you will get the exception, Secondary Namespaces can not be updated
Next, delete the secondary Namespace instance or Namespace and run
the pipeline. it will work.
If you not follow above step then you will get error unable to freeze secondary Namespace.
The above is the one time fix, if you run template again you have to repeat above process manually again.
2. Automation using CI-CD DevOps Pipeline or CLI or PowerShell
The most of the time ARM templates runs in the pipeline and there is option to break the pairing using the Azure CLI or PowerShell. You should consider the adding two task in the YAML file
First Task, to break the Pairing
Azure CLI
az servicebus georecovery-alias break-pair --resource-group myresourcegroup --namespace-name primarynamespace --alias myaliasname
PowerShell
Set-AzureRmServiceBusGeoDRConfigurationBreakPair -ResourceGroupName $resourcegroup -Name $aliasname -Namespace $primarynamespace
Second Task, to delete the secondary namespace instances (topic,
Queue) or delete entire Namespace.
PowerShell
Remove-AzServiceBusNamespace -ResourceGroup Default-ServiceBus-WestUS -NamespaceName SB-Example1
To remove Topic or Queue instead of Namespace, refer the following documentation.
Azure Service Bus Management Common PowerShell commands
Also if you are running template locally, you can add small script or CLI command prior to run your template.
Does it affect on ConnectionString or Data after deleting Secondary Namespace or instances?
Its valid question, what will happens to the connection string or data since some clients are already using it, The answer is connection string wont be change if we delete the secondary namespace because in Geo recovery scenario we are supposed to be use alias connection string so there is no impact on existing customers.
Regarding the second question about the data, the answer is secondary namespace wont store any data it has only the meta data, meaning in the case of failover secondary namespace start working.
So during the deployment deleting secondary namespace instances or namespace wont impact on anything.
Is there any better option?
Might be you are thinking, why should I follow such a long process but the above problem because of the Geo Recovery design (service bus, event hub, event grid etc.) and there is no other option.
I hope Microsoft will come up with some better approach in the future.
If you try to create a pairing between a primary namespace with a private endpoint and a secondary namespace without a private endpoint, the pairing will fail.
You could refer to this template allows you to configure Service Bus Geo-disaster recovery alias.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"serviceBusNamespaceNamePrimary": {
"type": "string",
"metadata": {
"description": "Name of Service Bus namespace"
}
},
"serviceBusNamespaceNameSecondary": {
"type": "string",
"metadata": {
"description": "Name of Service Bus namespace"
}
},
"aliasName": {
"type": "string",
"metadata": {
"description": "Name of Geo-Recovery Configuration Alias "
}
},
"locationSecondaryNamepsace": {
"type": "string",
"defaultValue": "South Central US",
"metadata": {
"description": "Location of Secondary namespace"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location of Primary namespace"
}
}
},
"variables": {
"defaultSASKeyName": "RootManageSharedAccessKey",
"defaultAuthRuleResourceId": "[resourceId('Microsoft.ServiceBus/namespaces/authorizationRules', parameters('serviceBusNamespaceNamePrimary'), variables('defaultSASKeyName'))]"
},
"resources": [
{
"apiVersion": "2017-04-01",
"name": "[parameters('serviceBusNamespaceNameSecondary')]",
"type": "Microsoft.ServiceBus/Namespaces",
"location": "[parameters('locationSecondaryNamepsace')]",
"sku": {
"name": "Premium",
"tier": "Premium",
"capacity": 4
},
"tags": {
"tag1": "value1",
"tag2": "value2"
}
},
{
"apiVersion": "2017-04-01",
"type": "Microsoft.ServiceBus/Namespaces",
"dependsOn": [ "[concat('Microsoft.ServiceBus/namespaces/', parameters('serviceBusNamespaceNameSecondary'))]" ],
"name": "[parameters('serviceBusNamespaceNamePrimary')]",
"location": "[parameters('location')]",
"sku": {
"name": "Premium",
"tier": "Premium",
"capacity": 4
},
"tags": {
"tag1": "value1",
"tag2": "value2"
},
"resources": [
{
"apiVersion": "2017-04-01",
"name": "[parameters('aliasName')]",
"type": "disasterRecoveryConfigs",
"dependsOn": [ "[concat('Microsoft.ServiceBus/namespaces/', parameters('serviceBusNamespaceNamePrimary'))]" ],
"properties": {
"partnerNamespace": "[resourceId('Microsoft.ServiceBus/Namespaces', parameters('serviceBusNamespaceNameSecondary'))]"
}
}
]
}
],
"outputs": {
"NamespaceDefaultConnectionString": {
"type": "string",
"value": "[listkeys(variables('defaultAuthRuleResourceId'), '2017-04-01').primaryConnectionString]"
},
"DefaultSharedAccessPolicyPrimaryKey": {
"type": "string",
"value": "[listkeys(variables('defaultAuthRuleResourceId'), '2017-04-01').primaryKey]"
}
}
}
I am going to configure created azure VM (for example, install role, initialize new hdd disk etc). I see that there is a new feature Microsoft.Resources/deploymentScripts in azure ARM. As per documantation I created Managed Identity in my subscription, give Contributor permissions to newly created Managed Identity, on Subscription level. then I developed below ARM template using Microsoft.Resources/deploymentScripts feature. code pasted below. I want to paste this code into my ARM template for VM deployment.Question is if I will be able to use this approach to perform scripts like: installing role on the OS level, like IIS or WSUS, configure HDD etc...
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"type": "string",
"defaultValue": "'John Dole'"
},
"utcValue": {
"type": "string",
"defaultValue": "[utcNow()]"
}
},
"resources": [
{
"type": "Microsoft.Resources/deploymentScripts",
"apiVersion": "2019-10-01-preview",
"name": "runPowerShellInlineWithOutput",
"location": "westeurope",
"kind": "AzurePowerShell",
"identity": {
"type": "userAssigned",
"userAssignedIdentities": {
"/subscriptions/SubID/resourceGroups/RGname/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MI-ARMdeployment": {}
}
},
"properties": {
"forceUpdateTag": "[parameters('utcValue')]",
"azPowerShellVersion": "3.0",
"scriptContent": "
$output = 'hello'
Write-Output $output",
"arguments": "",
"timeout": "PT1H",
"cleanupPreference": "OnSuccess",
"retentionInterval": "P1D"
}
}
]
}
Well, yes (with some hacks), but its not meant for that. Its meant for provisioning\configuring Azure level resources, not things inside of the VM.
You have DSC extension and script extension for that (available for both windows\linux).
I'm currently trying to script our Azure Machine Learning infrastructure, using ARM templates and running through Terraform. In order to ensure that the template works, I'm first running it from a file using the Az CLI.
I'm running this on Ubuntu, with the below version of the Az CLI:-
azure-cli 2.0.78
command-modules-nspkg 2.0.3
core 2.0.78
nspkg 3.0.4
telemetry 1.0.4
Python location '/opt/az/bin/python3'
Extensions directory '/home/blah/.azure/cliextensions'
Python (Linux) 3.6.5 (default, Dec 12 2019, 11:11:33)
[GCC 8.3.0]
I have already created the Storage Account, App Insights and Key Vault using terraform.
When trying to run the template using the Az CLI with the command:-
az group deployment create --name MachineLearning --resource-group data-science --template-file ML_ARM.json --parameters appInsightsName=machine-learning-dev storageAccountName=machinelearningdev keyVaultName=data-science-dev mlApiVersion=2018-11-19 mlWorkspaceName=machine-learning-dev location=uksouth
I receive the following error:-
Make sure to create your workspace using a client which support MSI
The ARM template is below:-
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountName": {
"type": "string",
"metadata": {
"description": "The name of the storage account"
}
},
"appInsightsName" : {
"type": "string",
"metadata": {
"description": "The name of the app insights account"
}
},
"keyVaultName": {
"type": "string",
"metadata": {
"description": "The name of the keyvault resource"
}
},
"mlApiVersion": {
"type": "string",
"metadata": {
"description": "The api version of the ML workspace"
}
},
"mlWorkspaceName": {
"type": "string",
"metadata": {
"description": "The name of the Machine Learning Workspace"
}
},
"location": {
"type": "string",
"metadata": {
"description": "Resource location"
}
}
},
"resources": [
{
"apiVersion": "[parameters('mlApiVersion')]",
"type": "Microsoft.MachineLearningServices/workspaces",
"name": "[parameters('mlWorkspaceName')]",
"location": "[parameters('location')]",
"sku": {
"tier": "enterprise",
"name": "enterprise"
},
"properties": {
"storageAccount": "[resourceId('Microsoft.Storage/storageAccounts',parameters('storageAccountName'))]",
"applicationInsights": "[resourceId('Microsoft.Insights/components',parameters('appInsightsName'))]",
"keyVault": "[resourceId('Microsoft.KeyVault/vaults',parameters('keyVaultName'))]"
}
}
]
}
Some rudimentary googling hasn't really been enlightening into what the issue might be with this; the documentation and guide templates for the Machine Learning Service are linked below:-
https://learn.microsoft.com/en-us/azure/machine-learning/service/how-to-create-workspace-template
https://learn.microsoft.com/en-us/azure/templates/microsoft.machinelearningservices/2019-11-01/workspaces
Any idea what the issue might be? Thanks in advance for any pointers!
I am not familar with Terraform or that robust on ML Services; however, the error you provided lends itself to needing to have MSI authentication configured which is configured in the link you provided.
Try updating your ARM to include the identity section like this:
... },
"identity": {
"type": "systemAssigned"
},
"properties": {
"storageAccount": "[resourceId('Microsoft.Storage/storageAccounts',parameters('storageAccountName'))]",
"applicationInsights": "[resourceId('Microsoft.Insights/components',parameters('appInsightsName'))]",
"keyVault": "[resourceId('Microsoft.KeyVault/vaults',parameters('keyVaultName'))]"
}
This will create the Managed Service Identity.
I am currently deploying a VM Scale Set (VMSS) using an ARM template which has a resource inside VMSS to install Azure extension for Azure DevOps (ADO) Deployment Agent. All is deployed successfully and a node is registered in ADO with all details as are in the ARM template. However the problem is that it installs the agent only on first node and (as far as I see) ignores the rest of the nodes. I've tested this with multiple nodes during creation of the scale set and with auto-scale as well. Both scenarios result in only first agent registered.
This is the code layout I'm using (I've removed the VMSS bits to reduce the template length here, there are of course OS, storage and network settings inside):
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "[parameters('VMSSName')]",
"apiVersion": "2018-10-01",
"location": "[resourceGroup().location]",
"sku": {
"name": "[parameters('VMSSSize')]",
"capacity": "[parameters('VMSSCount')]",
"tier": "Standard"
},
"dependsOn": [],
"properties": {
"overprovision": "[variables('overProvision')]",
"upgradePolicy": {
"mode": "Automatic"
},
"virtualMachineProfile": {},
"storageProfile": {},
"networkProfile": {},
"extensionProfile": {
"extensions": [
{
"type": "Microsoft.Compute/virtualMachineScaleSets/extensions",
"name": "VMSS-NetworkWatcher",
"location": "[resourceGroup().location]",
"properties": {
"publisher": "Microsoft.Azure.NetworkWatcher",
"type": "[if(equals(parameters('Platform'), 'Windows'), 'NetworkWatcherAgentWindows', 'NetworkWatcherAgentLinux')]",
"typeHandlerVersion": "1.4",
"autoUpgradeMinorVersion": true
}
},
{
"type": "Microsoft.Compute/virtualMachineScaleSets/extensions",
"name": "VMSS-TeamServicesAgent",
"location": "[resourceGroup().location]",
"properties": {
"publisher": "Microsoft.VisualStudio.Services",
"type": "[if(equals(parameters('Platform'), 'Windows'), 'TeamServicesAgent', 'TeamServicesAgentLinux')]",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"VSTSAccountName": "[parameters('VSTSAccountName')]",
"TeamProject": "[parameters('VSTSTeamProjectName')]",
"DeploymentGroup": "[parameters('VSTSDeploymentGroupName')]",
"AgentName": "[concat(parameters('VMSSName'),'-DG')]",
"Tags": "[parameters('VSTSDeploymentAgentTags')]"
},
"protectedSettings": {
"PATToken": "[parameters('VSTSPATToken')]"
}
}
}
]
}
}
}
}
Now the desired state, of course, is that all nodes will have agent installed so that I can use the Deployment Group inside Release pipeline.
your problem is in the fact that all agents have the same AgentName, so it effectively overwrites the agent and only the latest one "survives". I dont think there is anything you can do, unless you just amend the AgentName and it auto assigns based on computer name.
You can convert this to a script\dsc extension, that way you can calculate everything on the fly.