When i run the "Get-AzureVirtualNetworkGatewayConnection -Name Connection -ResourceGroupName POC -Debug" cmdlet the Provisionstate is Failed. I have delete the connection serveral times without any success.
Here the results:
{
"name": "GWConnection1",
"id": "/subscriptions/ed9cc7cb-a0e4-455c-8a65/resourceGroups/POC/providers/Microsoft.Network/connections/GWConnection1",
"etag": "W/\"e66d8c6f-d4a5-4bb1-80d2\"",
"type": "Microsoft.Network/connections",
"location": "eastus2",
"properties": {
"provisioningState": "Failed",
"resourceGuid": "1d6261cc-6a03-4efe-a492",
"virtualNetworkGateway1": {
"id": "/subscriptions/ed9cc7cb-a0e5-455c/resourceGroups/POC/providers/Microsoft.Network/virtualNetworkGateways/Gateway"
},
"localNetworkGateway2": {
"id": "/subscriptions/ed9cc7cb-a0e4/resourceGroups/POC/providers/Microsoft.Network/localNetworkGateways/PR-Network"
},
"connectionType": "IPsec",
"routingWeight": 10,
"sharedKey": "308201A006092A864886F70D010703A08201913082018D0201003182014930820145020100302D3019311730150603550403130E6E72702D656E6372797074696F6E021072E532F90B53108C4B29C242F8C9C148300D06092A864886F70D010101050004820100089C2DE40C535B5B43E641E5B867618E099169D567CD4BA6",
"connectionStatus": "Unknown",
"ingressBytesTransferred": 0,
"egressBytesTransferred": 0
}
}
NVM, I found the problem. I think it was that my local network is 192.168.0.0/24 and the azure network was 192.168.0.0/16 and the subnet was 192.168.1.0/24 and the gateway subnet was 192.168.3.0/24.
Although the local network and subnetworks dont overlap the address space was overlapping.
Related
I need to find the current usage of IP addresses within subnets in Azure. I found free IPs in Virtual Networks->subnets but the number is the total available IP addresses within the subnet. How can I see how many of the available IPs within the subnet are actually in use (how many of them are free)? Is there a way to set the monitoring for free IP addresses (or used IP addresses) for Azure subnets?
Thanks in advance.
You can call the listUsage API /subscriptions/****/resourceGroups/aoprod9574-stamp-canadacentral-rg/providers/Microsoft.Network/virtualNetworks/vnet-name/usages?api-version=2021-02-01 to get the current allocations per Subnet in a VNet
{
"value": [
{
"currentValue": 3,
"id": "/subscriptions/****/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/aoprod9574-canadacen-vnet/subnets/cosmosdb-pe-snet",
"limit": 27,
"name": {
"localizedValue": "Subnet size and usage",
"value": "SubnetSpace"
},
"resourceGroup": "my-rg",
"unit": "Count"
},
{
"currentValue": 93,
"id": "/subscriptions/****/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/aoprod9574-canadacen-vnet/subnets/kubernetes-snet",
"limit": 1019,
"name": {
"localizedValue": "Subnet size and usage",
"value": "SubnetSpace"
},
"resourceGroup": "my-rg",
"unit": "Count"
}
]
}
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 creating an Azure Web app with the name "CustomerX-app-001" the default custom domain that Azure creates after the creation of the Azure web app is : "Customerx-app-001.azurewebsites.net".
Inside my arm template I've tried to change this default hostname to "Customerx-app.azurewebsites.net" by doing these 2 solutions:
Adding the hostnamebinding resource inside the resource block of microsoft.web/sites
"resources": [
{
"type": "hostNameBindings",
"apiVersion": "2018-11-01",
"name": "[concat(parameters('CustomHostname'), '.azurewebsites.net')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('siteName'))]"
],
"properties": {
"siteName": "[parameters('siteName')]"
}
},
**Adding the hostnamebinding resource outside as a new resource block **
{
"type": "Microsoft.Web/sites/hostNameBindings",
"apiVersion": "2018-11-01",
"name": "[concat(parameters('siteName'), '/', parameters('CustomHostname'), '.azurewebsites.net')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('siteName'))]"
],
"properties": {
"siteName": "[parameters('siteName')]",
"hostNameType": "Verified"
}
}
With CustomHostname being: "Customerx-app" and sitename being "Customerx-app-001"
Both solutions gave me the same error:
"Code": "BadRequest",
"Message": "Too many (2) hostnames in the default DNS zone. Limit is 1.",
"Target": null,
"Details": [
{
"Message": "Too many (2) hostnames in the default DNS zone. Limit is 1."
},
{
"Code": "BadRequest"
},
{
"ErrorEntity": {
"ExtendedCode": "04017",
"MessageTemplate": "Too many ({0}) hostnames in the default DNS zone. Limit is {1}.",
"Parameters": [
"2",
"1"
],
"Code": "BadRequest",
"Message": "Too many (2) hostnames in the default DNS zone. Limit is 1."
}
}
I am stuck at this for a while and figuring out why the problem occurs.
I think that the azure web app has 1 default DNS name that you can't change and that is always the name of the web app. If another DNS name needs to be added a new DNS record should be made and this record can be added to the web app. But solution 2 does exactly that with the only difference that the DNS name does not exist.
Is there anyone who can help me out here, or guide me in the right direction ?
You can only use a single *.azurewebsites.net dns name and it is being autogenerated. You can only add dns names on a domain you own (and you'd have to validate it first).
We have some Azure Table storage tables in our subscription and would like to migrate them to CosmosDB table API due to performance reasons. To do this, I started creating cosmos db account by selecting Table API but my deployment failed with the following error. When i tried with SQL API, it works.
{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. "details":[{"code":"BadRequest","message":"{\r\n \"code\": \"BadRequest\",\r\n \"message\": \"CORS rules are not supported for this API\rMicrosoft.Azure.Documents.Common/2.1.0.0\"\r\n}"}]}
Can someone please let me know what could be the reason for this?
#AngiSen, may be related to a recent (breaking) update of Azure Cosmos DB resource provider (Microsoft.DocumentDb/databaseAccounts) as I just noticed today (28th of Nov 2018) that a previously running deployment (as of 23th of Nov 2018) of Cosmos DB Table API is now failing with this same error:
9:16:23 AM - Resource Microsoft.DocumentDb/databaseAccounts 'xxx-xxx-xxx' failed with message '{
"code": "BadRequest",
"message": "CORS rules are not supported for this API\r\nActivityId: xxx, Microsoft.Azure.Documents.Common/2.1.0.0"
}'
In my case I'm using 2015-04-08 version with Table API but I don't configure explicitly the CORS part and anyway there's no such configuration option in the resource provider.
Digging into the existing Cosmos DB instance with https://resources.azure.com shows there's indeed a CORS member that is part of the definition:
{
"id": "/subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.DocumentDB/databaseAccounts/xxx",
"name": "xxx",
"location": "North Europe",
"type": "Microsoft.DocumentDB/databaseAccounts",
"kind": "GlobalDocumentDB",
"tags": {},
"properties": {
"provisioningState": "Succeeded",
"documentEndpoint": "https://xxx.documents.azure.com:443/",
"tableEndpoint": "https://xxx.table.cosmosdb.azure.com:443/",
"ipRangeFilter": "",
"enableAutomaticFailover": false,
"enableMultipleWriteLocations": false,
"isVirtualNetworkFilterEnabled": false,
"virtualNetworkRules": [],
"EnabledApiTypes": "Table, Sql",
"databaseAccountOfferType": "Standard",
"consistencyPolicy": {
"defaultConsistencyLevel": "BoundedStaleness",
"maxIntervalInSeconds": 86400,
"maxStalenessPrefix": 1000000
},
"configurationOverrides": {},
"writeLocations": [
{
"id": "xxx-northeurope",
"locationName": "North Europe",
"documentEndpoint": "https://xxx-northeurope.documents.azure.com:443/",
"provisioningState": "Succeeded",
"failoverPriority": 0
}
],
"readLocations": [
{
"id": "xxx-northeurope",
"locationName": "North Europe",
"documentEndpoint": "https://xxx-northeurope.documents.azure.com:443/",
"provisioningState": "Succeeded",
"failoverPriority": 0
}
],
"locations": [
{
"id": "xxx-northeurope",
"locationName": "North Europe",
"documentEndpoint": "https://xxx-northeurope.documents.azure.com:443/",
"provisioningState": "Succeeded",
"failoverPriority": 0
}
],
"failoverPolicies": [
{
"id": "xxx-northeurope",
"locationName": "North Europe",
"failoverPriority": 0
}
],
"cors": [],
"capabilities": [
{
"name": "EnableTable"
}
]
}
}
Hope it'll get fixed quickly if it's indeed a breaking change...
Wanted to make an official statement here. I have spoken with the Cosmos DB team and they have a fix ready and it should be deployed tonight. Please let me know if you should have any questions. Thank you for posting the issue.
As you can see below, I create a group, and then try and create a k8s cluster in this group, getting an error that 'default' doesn't exist. If i then wait another 15 minutes, the error changes. The 'DefaultResourceGroup-CCA' exists immediately, but not as 'defaultresourcegroup-cca', is this case sensitive?
Do you have a suggestion for either of these two errors?
If i delete the '--enable-addons monitoring', the 2nd error goes away, and it works (as long as I have waited ~15 minutes after the group create).
$ az group create --name socks --location canadacentral
{
"id": "/subscriptions/187362fc-9705-4173-9056-6bd387695cf0/resourceGroups/socks",
"location": "canadacentral",
"managedBy": null,
"name": "socks",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
don#cube:~/src-ag/corp-tools/gitlab-runner$ az group list
[
{
"id": "/subscriptions/187362fc-9705-4173-9056-6bd387695cf0/resourceGroups/DefaultResourceGroup-CCA",
"location": "canadacentral",
"managedBy": null,
"name": "DefaultResourceGroup-CCA",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
},
{
"id": "/subscriptions/187362fc-9705-4173-9056-6bd387695cf0/resourceGroups/socks",
"location": "canadacentral",
"managedBy": null,
"name": "socks",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
]
don#cube:~/src-ag/corp-tools/gitlab-runner$ az aks create --resource-group socks --name sock-shop --node-count 1 --node-vm-size Standard_F4s_v2 --enable-addons monitoring --generate-ssh-keys
Resource group 'defaultresourcegroup-cca' could not be found.
don#cube:~/src-ag/corp-tools/gitlab-runner$ az aks create --resource-group socks --name sock-shop --node-count 1 --node-vm-size Standard_F4s_v2 --enable-addons monitoring --generate-ssh-keys
Operation failed with status: 'Bad Request'. Details: Unable to get log analytics workspace info. Resource ID: /subscriptions/187362fc-9705-4173-9056-6bd387695cf0/resourcegroups/defaultresourcegroup-cca/providers/microsoft.operationalinsights/workspaces/defaultworkspace-187362fc-9705-4173-9056-6bd387695cf0-cca. Detail: operationalinsights.WorkspacesClient#GetSharedKeys: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound" Message="The Resource 'Microsoft.OperationalInsights/workspaces/defaultworkspace-187362fc-9705-4173-9056-6bd387695cf0-cca' under resource group 'defaultresourcegroup-cca' was not found."
We are currently experiencing an outage in South Central US that is affecting ARM
https://azure.microsoft.com/en-us/status/
You will want to monitor the Azure Status Page for further updates. Unfortunately we cannot do anything until the problem has been mitigated by engineering.