I would like to create a new Azure Cosmos DB under my free MPN Subscription and would like to set the location to "(Europe) West Europe" just like I did for my ResourceGroup, but this location (and a lot of other locations) is not available?
See the complete list here
If I create a new Resource Group it's not a problem to choose "(Europe) West Europe" and all the other locations/regions that I can normally choose among.
Anyone who knows why this happens and what I can do to fix it?
You can still create resources in West Europe. The locations are unlisted but still available when you create your resources using ARM templates.
To achieve this, follow these simple steps:
configure your resource up to the point where you need to create it, but use one of the listed locations. Do not create the resource.
In the "Review + Create" page of the wizard, choose "Download a template for automation".
Choose Deploy
Change 'Location' to westeurope and 'Location Name' to West Europe, agree terms and conditions and click 'Purchase'
I think this would be due to recent compute shortages in Microsoft Azure due to SARS-COV-2. All the free subscriptions are affected**
https://www.zdnet.com/article/microsoft-cloud-services-demand-up-775-percent-prioritization-rules-in-place-due-to-covid-19/
Related
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 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.
I am trying to find a way to retrieve the JSON version of an Azure Resource Group that I created in the portal. I've looked through all the PowerShell documentation, tried scraping JSON from the portal, all to no avail. There are some earlier questions that state that it isn't supported, but they are all fairly old (in terms of Azure feature release speed).
Is there any way to get the JSON for a Resource Group created in the Portal UI? Or is the template approach the only way to go?
While it is possible to retrieve the JSON for a resource group from the Azure Resource Explorer, there are some caveats you need to be aware of.
Resource Explorer is a tool that describes the current runtime configuration rather than the deployment configuration that a resource template does. While it is primarily the same language there are a number of subtle differences.
For instance resource explorer will tell you the IP address that is assigned to a NIC, which isn't something that is possible to assign from a template.
While they can be a good starting point for building resource templates you will need to go through them and clean out the extraneous information.
Personally my three calling points in building resource templates are
Azure Resource Explorer
Azure Quickstart Templates
Azure Resource Manager Schemas
Between the three of those you can usually put together some concise, powerful templates.
There is a feedback item that is 'under review' to allow for the creation of full ARM templates from existing resource groups.
You can use the Azure Resource Explorer to view the JSON representation of your Azure resources. The source code is also available on GitHub in case if you want to learn how it works: https://github.com/projectkudu/ARMExplorer
This is now available in the Azure portal, portal.azure.com. If you browse to a resource group in the portal, under "All settings" for the resource group, there is now an "Export template" option.
Looking at portal.azure.com as of 3/28/2016 it looks like the options have changed from some of the previous responses...
Go to portal.azure.com and log in
Click on "Resource Groups"
Click on "All Settings"
Click on "Deployments"
Click on the particular resource/deployment for which you want to create a template
Click on "Export Template" near the top of the tile/page.
Note: Some of the deployments may not give access to the "Export Template" button. For these, you will most likely see a "Template Link" in the resource summary which gives access to the generic template for that resource deployment.
After the new model was implemented, all of my websites now belong to individual Resource Groups called "Default-Web-East" and all of my SQL databases belong to individual Resource Groups called "Default-SQL-East".
This is confusing to say the least.
I would like to rename the groups to have some semantic meaning. I would also like to group the associated SQL database and Web Site in the same Resource Group.
However, I do not see anyway to do either. Is this possible?
1) Rename the Resource Group?
2) Combine an existing SQL DB and Website together into one Resource Group?
Edit: You can't rename an Azure Resource Group.
What you can do is move your resources to a new Resource Group instead. Moving all resources in Resource Group A to Resource Group B is the poor man's rename.
Unfortunately not all resource providers let you move resources between resource groups, and some that do might have strings attached that only let you move resources under certain conditions.
For Azure Web Apps (previously called Azure Websites) you can currently only move all the websites related resources in a single invocation. That "all websites related resources" means all resource under the provider "Microsoft.Web". This includes all websites, app hosting platforms, and certificates that are in the source resource group.
Via the portal
When viewing a group's resources, you can use the "Move" tab
Clicking the "Move" tab will show something this, allowing you to choose or create a new group:
Via Azure Powershell
The easiest way to do this is to use the Move-AzureRmResource powershell cmdlet.
The command would look like this:
Get-AzureRmResource -ResourceGroupName <sourceResourceGroupName> | Move-AzureRmResource -DestinationResourceGroupName <destResourceGroupName>
source: https://azure.microsoft.com/en-us/documentation/articles/resource-group-move-resources/
Via Rest API
The other way to do this is to use the MoveResource Rest API or with the ArmClient.
Here's the API call you'll want to make:
POST https://<endpoint>/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/moveResources?api-version={api-version}
Where {resourceGroupName} is the source resource group.
I'm pretty sure the endpoint should be "https://management.azure.com", but if you use the ArmClient the tool will just take care of the endpoint for you.
Request Body:
{
"targetResourceGroup": "/subscriptions/{subscriptionId}/resourceGroups/{targetResourceGroupNameName}",
"resources":
[
"/subscriptions/{id}/resourceGroups/{source}/providers/{namespace}/{type}/{name}",
"/subscriptions/{id}/resourceGroups/{source}/providers/{namespace}/{type}/{name}"
]
}
In addition to the main answer, Azure Portal has a feature of moving the Resources that is allowed to be moved to a new Resource group.
Go to your Resource Group that has Resources you want to move to an existing or a new created Resource Group.
Select the one, multiple or all (1) Resources you want to move and click on the Move (2) bottom as shown in image. (you can select moving to Resources with in the same subscription or to another subscription) A third option if you need just to change the Region) see the the figure at the end.
It will ask you to chose which Resource Group to move to.
Note: This process might take some time, be patient. When done, you
will see that the resource disappear from the old one and will be
found in the new one. That said some resources might be restricted
from been moved to other resources.
Move (Fixing) only region
Our Windows Azure roles need to know programmatically which datacenter the roles are in.
I know a REST API ( http://msdn.microsoft.com/en-us/library/ee460806.aspx) return location property.
And if I deploy to, let’s say, West US, the REST API returns West US as location property.
However, if I deploy to Anywhere US, the property is Anywhere US.
I would like to know which datacenter our roles are in even if location property is Anywhere US.
The reason why I ask is our roles need to download some data from Windows Azure storage.
The cost of downloading data from the same datacenter is free but the that of downloading data from the different datacenter is not free.
It is a great question and I have talked about it couple of time with different partners. Based on my understanding when you create your service and provide where you want this service to location ("South Central US" or "Anywhere US"), this information is stored at the RDFE server specific to your service in your Azure subscription. So when you choose a fixed location such as "South Central US" or "North Central US" the service actually deployed to that location and exact location is stored however when you choose "Anywhere US", the selection to choose "South Center" or "North Central" is done internally however the selected location never updated to RDFE server related to your service.
That's why whenever you try to get location info related to your service in your subscription over SM API or Powershell or any other way (even on Azure Portal it is listed as "Anywhere US" because the information is coming from same storage), you will get exactly what you have selected at first place during service creation.
#Sandrino idea will work as long as you can validate your service location IP address from a given IP address range published by Windows Azure team.
Two days ago Microsoft published an XML file containing a list of IP ranges per region. Based on this file and the IP address of your role you can find in which datacenter the role has been deployed.
<?xml version="1.0" encoding="UTF-8"?>
<regions>
...
<region name="USA">
<subregion name="South Central US">
<network>65.55.80.0/20</network>
<network>65.54.48.0/21</network>
...
</subregion>
<subregion name="North Central US">
<network>207.46.192.0/20</network>
<network>65.52.0.0/19</network>
...
</subregion>
</region>
</regions>
Note: It looks like the new datacenters (West and East US) are not covered by this XML file, which might make it useless in your case.
I had some services deployed in Anywhere US and in order to find out which data centre it was deployed in I had to log a support call with Microsoft. They were helpful and got me the information but even they had to go away and look it up. As a result of this I would never use and the the "Anywhere ..." locations. Knowing which data centre your services are running in is very important for knowing where to deploy things like SQL Azure and service bus which don't support affinity groups and don't have an Anywhere option.