I need to create a DINE policy, but it has to deploy different resources depending on the region.
For example:
If I am deploying in West Europe, I need to "DeployIfNotExist" a resource in West Europe.
If I am deploying in East US 2, I need to "DeployIfNotExist" a resource in East US 2.
Scenario:
I am adding to the diagnostic settings of Azure SQL, a link to EventHub (which is already existing in weu or eus2)
Is that possible todo?
** I know we can create two policies with the existing condition checking the region, but I am looking for a solution to do it in a single policy. **
Related
I know that Azure Resource group must be created with a location, because that is where the metadata for that RG will reside.
Our application currently has a resource group in a location (eg : East US) that contain resources located in multiple regions. (eg : East US and Central US).
What happens to my Central US resources if East US goes down?
To be more specific :
Does the availability of the region hosting the RG itself affect the availability of the resources in another Region? (My guess in the example above is that the resources in Central US should still be running ok).
In the example above, is it still possible to manage the Central US resources if the location hosting the RG (East US) is down? This one is much less clear.
no, the availability of the region Resource Group hosted in doesn't affect availability of the resources in it.
you can only read those resources, as Resource Group region is responsible for writes
you won't be able to use template deployments as well
in regions with zones all zones have to go down for writes to be not available.
reading: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#resource-groups
I have a cloud service and a storage account deployed using the classic resource manager in the East US region; there is also a classic backup vault in the West Europe region.
Due to high latency, I want to move all of these resources to the UK South region, which is the closest one to me and others using these services. I have created a new resource group in the UK South region, however, when I try to move my existing classic resources to the new resource group, it says:
Classic resources must be moved separately and aren't displayed below.
Reading the article it linked to, it says that to move classic resources when experiencing this limitation, I need to contact support to have this operation done manually.
I do not have a support plan and am hoping not to buy one for this single task. Is there any other way around this limitation?
I think that you can walk around it by:
1. Create a new blank cloud service in your new resource group in UK South region.
2. Modify the deployment process to deploy the code to the newly created cloud service.
I hope this helps.
As you mentioned that it is limited by Azure. The following is snippet from the official document.
When moving resources from one resource group to another resource group within the same subscription, the following restrictions apply:
Virtual networks (classic) cannot be moved.
Virtual machines (classic) must be moved with the cloud service.
Cloud service can only be moved when the move includes all its virtual machines.
Only one cloud service can be moved at a time.
Only one storage account (classic) can be moved at a time.
Storage account (classic) cannot be moved in the same operation with a virtual machine or a cloud service.
As Toan nguyen mentioned that we need to redeploy it if you don't want to call Azure Support.
Really puzzled why I am not seeing all locations - only 4 - US West, US East, Japan West and Japan East in my trial subscription. Is there any filtering I inadvertently setup?
Any pointers would be really helpful
Shas
I am giving many workshops for Azure and I see this behavior a lot for Azure Passes (also kind of trial accounts) but have not seen this for Azure Trials.
I noticed that I have more location options in the new Azure portal (https://portal.azure.com) and less in the old management portal (https://manage.windowsazure.com).
Also to consider, not all services are available at all locations. But the standard services like VMs or storage should be available everywhere. You can check via the service overview whether your desired service is available.
While creating a new Resource Group or app service plan/ location on new Azure Management portal, I get the following error.
Error submitting the deployment request. Additional details from the underlying API that might be helpful: The provided location 'Central India' is not permitted for subscription. List of permitted regions is 'eastasia,southeastasia,eastus,eastus2,westus,northcentralus,southcentralus,centralus,northeurope,westeurope,japaneast,japanwest,brazilsouth'. Please contact support to change your supported regions.
This is when I try & select any Indian reagions for the service. I've tried with Central India, West India & South India.
What's wrong? Are Indian regions allowed to be selected for creating new resource groups or app plans? Is this something to have with my subscription? Can I change my existing Resource group's region?
Any help is appreciated.
Thanks
Supreet
As of today, Azure DCs are not open for general consumption in India. Right now only EA and some other hand-picked customers have their subscriptions enabled to make use of India DCs.
So in short, your Subscription is not enabled for creation of the resources in India DC. You will just have to wait till the time they open the DCs here in India for general public (or in other words Pay As You Go subscription).
Quoting from https://azure.microsoft.com/en-in/regions/:
The India regions are available to volume licensing customers and
partners with a local enrolment in India. The India regions will open
to direct online Azure subscriptions in 2016.
I have a webservice which uploads data to blob store. I have 2 deployments of this webservice, on in south east asia and one in US. Each deployment has a different storage account associated with it(while creating a cloud service you can associate a storage account with it), say StorageSEA and StorageUS.
As of now, I read the storage account connection string from the config, which means that when I deploy to southeast asia I have to go and update the connection string to point to StorageSEA and change it to StorageUS when publishing to US. This doesn't seem like a approach I will be able to sustain in future, as I plan to go ahead with more deployments.
So I was wondering if there was a way to get the associated storage account instead of updating the config file for each deployment.
There are two solutions I could think of:
Use config transformation to create 2 separate deployment configuration files - one for South East Asia and other one for US. Each config file will have storage account for that data center.
Programmatically identify the deployment location - In this case, you would define both storage account connection string in your configuration file. When the role starts up, you would find the data center location of the cloud service and based on that you pick up one of the values. For this to work, you would need to implement Service Management API's Get Hosted Service Properties operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460806.aspx).