I have an interesting issue in Azure where somehow I've had some resources assign themselves to "Default-Web-NorthEurope" and some to "Default-Web-northeurope". (Note capitalisation)
Lets say I have Website1 and Website2. I'd like both of these to belong to the same App Service Plan. If I create a new one for "Website1" named "WebsitesServicePlan" The UI won't show me that plan when trying to change the plan for "Website2".
Has anyone else come across this issue and have any idea of a solution?
First of all, Azure Resource Group naming is not case sensitive. So I've no idea how you created two resource groups with the name Default-Web-NorthEurope and Default-Web-northeurope successfully. I suggest you double check the names in the portal.
Assume that the Default-Web-NorthEurope and Default-Web-northeurope are different groups and as you descriped Website1 is in Default-Web-NorthEurope, Website2 in Default-Web-northeurope, UI will definitely not show you the App Service Plan you created for "Websites1" when trying to change the plan for "Website2". Because both apps and plans are contained in a resource group. Apps can be moved between plans as long as the plans are in the same resource group and geographical region. In other words, when you want to change plans for app, the plans must be in the same resource group and geographical region.
Check azure-web-sites-web-hosting-plans-in-depth-overview for details.
Related
Currently for our Azure Disaster recovery plan we replicate workloads from a primary site/region to a secondary site. Where we mirror the source VM config and create required or associated resource groups, storage accounts, virtual networks, etc.
We are looking into an alternate method the wouldn't require a second resource group. This would require:
Use one, already existing resource group; i.e. testGroup-rg in East-US
Deploy new IaC components into the same RG but in Central-US
So in the singular resource group, if we wanted a function app, we would have two sets of components. testFuncApp in East-US and testFuncApp in Central-US.
This way we would only ever have one set of IaC created. Of course we would need to automate how to flow traffic etc. into a particular region if both exist.
Is this a possibility? If it is, is it even necessary/worth it?
Unfortunately there is no way to use the same RG. We need to have a resource group in target region if not Site Recovery creates a new resource group in the target region, with an "asr" suffix.
I have an Azure App Service Plan and a Web App. I want to move them to another subscription. There is a limitation that app service plan and app service must be moved together from the origin resource group of the app service plan. Someone had moved the resources from their origin resource group and deleted the resource group. Now, how can I find the name of the origin resource group ?
In some cases it can be found in the WebSpace property of app service plan. For example [ "webSpace": "RG-SK-MarkIII-CentralUSwebspace" ], RG-SK-MarkIII is the origin resource group of the app plan. But in my case the webSpace is like this ["webSpace": "AustraliaEastwebspace" ]. Is there any other way to find it through CloudShell ?
You can look up the actions taken by a particular user, even for a resource group that no longer exists.
az monitor activity-log list -g ExampleGroup --caller someone#contoso.com --offset 5d
Kindly try these steps:
If you don't remember the original resource group, you can find it through diagnostics.
For your web app, select Diagnose and solve problems.
Then, select Configuration and Management.
Select Migration Options.
Select the option for recommended steps to move the web app.
You see the recommended actions to take before moving the resources. The information includes the original resource group for the web app.
- I understand you're referring to RG deletion scenario, kindly try this and let me know how it goes.
Reference document move across subscription.
Furthermore, you can only change to a plan that was created in the same "webspace" as your original app. Webspace is an internal concept that's not exposed, but you can verify whether your source and destination plans are in the same webspace or not.
To verify, do the following:
https://resources.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/serverfarms/{serverFarmName}
Confirm whether the webSpace property of your source plan matches the webSpace property of your new plan
I am having different slots for a web app on azure for dev, test, production. I need to move different slots to their respective resource groups.
Can different slots for a single web app be in different resource groups? I tried to move a slot to different resource but gives me error (The list of resources in move definition cannot be null or empty. (Code: InvalidResourceMoveRequest)). Cannot make out much from the error. Is there a way to get more details on this error somewhere?
Thanks!
Can different slots for a single web app be in different resource groups?
You could not move the slot to other resource group, because the azure slot is not a top level resource.
This means that you could move the top level resource in order to move the child resource.
You could get more details about the limitation when moving resources to new group or subscription.
I have created one Azure Function App in an existing Azure Resource Group. While creating a Function App, by mistake I didn't notice the selected region, and it got created in "South Central US" region. After a significant development, I realized this mistake, and now want to move it to "West Europe" region, so it gets aligned with rest of my resources.
Any idea of how I can move a resource from one region to other region, without deleting and recreating?
There is still no way to change your deployment from one region to the other. You'll have to create another Azure Function in that correct region and redeploy your application.
Troy Hunt outlines his journey with an Azure Website here but the same steps still apply.
still, I don't see any new option (We can move resources from one resource group/ subscription level).
I think as of now 3 options available
Create a resource in the new region then delete existing resource.
Deploy new resource with the same configuration using PowerShell/CLI.
Deploy through portal (Export Template > Deploy > Select New region > change parameters then Purchase) similar to option 2, but you don't need to write any script.
Ultimately all three options would create a new resource and you need to update access key in the dependent services. I think option 2 is a good choice for a production workload.
I would like to keep each VM in separate resource group for ease for lifecycle management. I have a cluster containing n VLMs.
So I create one resource group for common things like public IP, load balancer and put availabilitySet declaration into it because is also must be shared between VMs.
Then I create VM in separate resource group and reference to availabilitySet with
"availabilitySet": {
"id": "[resourceId('Microsoft.Compute/availabilitySets',variables('availabilitySetName'))]"
},
Of cause 'availabilitySetName' is defined.
When I deploy my template I get an error saying
{"error":{"code":"BadRequest","message":"Entity resourceGroupName in resource reference id /subscriptions/a719381f-1fa0-4b06-8e29-ad6ea7d3c90b/resourceGroups/TB_PIP_OPSRV_UAT/providers/Microsoft.Compute/availabilitySets/tb_avlbs_opsrv_uat is invalid."}}
I double checked that resource and availability set name are specified correctly.
Does it mean that I can't put a set in separate resource group from VM?
Unfortunately, having a VM use an availabilitySet in a different resource group is not supported :(.
First of all, let me ask you why you want different resource groups? I strongly believe that you're overthinking it with multiple resource groups. A resource group is basically your "Entire System" and within the boundaries of one solution, you should only have one resource group for production, one for beta/staging etc, but never mix.
If you're selling SaaS to your customers it would make sense to have one resource group for each of your customers.
And as you know, a Resource group is simply a way for you to link together and manage all of the assets in your solution; vm's, storage, databases etc under one common name. I am very doubtful as to why one would want to consider multiple resource groups in a single solution, however, I am always willing to learn :)
Availability groups
Now, Availability groups are a different thing. This has to do with "Update Domains" and "Fault Domains" for your VM instances. Because Azure does not keep 3 separate VM's for you, as it does with most of it's PaaS services, you have to manage these yourself to ensure full uptime. Basically, when you're adding two or more VM's in an Availability Set, you're ensured that planned or unplanned events, at least one of the VM's will be available to meet the SLA.
Trying to combine the two in an effort of preventing downtime may sound like a good idea, but it is not solving any problems that I'm aware of. Like the old saying goes: if it aint broke, don't fix it :)