Azure website resource template error

Question

I\'m attempting to use the AzureResourceManager PowerShell module to create and configure a website. I started with a template file generated by Visual Studio, which works

Answer 1

Never fails, as soon as I write out the question I figure out the answer.

The error means that because this is a nested resource (the config object is nested inside the site object) the name needs to reflect this. So instead of config the name should be something like mysite/config. I also needed to add the dependsOn section. Here's the template that validated successfully:

"resources": [
    {
        "apiVersion": "2014-04-01",
        "type": "Microsoft.Web/sites/config",
        "name": "[concat(parameters('siteName'), '/config')]",
        "dependsOn": [
            "[concat('Microsoft.Web/sites/', parameters('siteName'))]"
        ],
        "properties": {
            "phpVersion": "",
            "netFrameworkVersion": "V4.5"
        }
    }
]

Answer 2

You may find the answer here. For child resources, the type and name have the same number of segments. This number of segments makes sense because the full name and type for the child includes the parent name and type. Therefore, the full name still has one less segment than the full type.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/error-invalid-template

Answer 3

The 'incorrect segment lengths' error message is difficult to understand for non-English native so there's explanation in plain English/json: For example, you have a resource of type Microsoft.Network/trafficManagerProfiles resource and for some reason you need to define nested resource having type Microsoft.Network/trafficManagerProfiles/ExternalEndpoints as a separate resource.

The nested resource must have name parent_resource_name/nested_res_name

The correct (simplified) schema is:

{
  "type": "Microsoft.Network/trafficManagerProfiles",
  "name": "[variables('trafManagerProfileName')]",
   ...
},
{
  "type": "Microsoft.Network/trafficManagerProfiles/ExternalEndpoints",
  "name": "[concat(variables('trafManagerProfileName'), '/Endpoint', copyIndex())]",
  "dependsOn": [
    "[concat('Microsoft.Network/trafficManagerProfiles/', variables('trafManagerProfileName'))]",
    "[parameters('app_name')]" # where the endpoint should look at
  ],
   ...
}

p.s. you might be interested in this question as well if you need to generate nested resources dynamically based on count of third resource: How do I dynamically generate Traffic Manager endpoints in an ARM template?

Answer 4

Something like this happened to me with Vnet-peering. I used this template from Microsoft's documentation:

{
     "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
     "contentVersion": "1.0.0.0",
     "parameters": {
     },
     "variables": {
     },
 "resources": [
         {
         "apiVersion": "2016-06-01",
         "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
         "name": "myVnetA/myVnetAToMyVnetB",
         "location": "[resourceGroup().location]",
         "properties": {
         "allowVirtualNetworkAccess": true,
         "allowForwardedTraffic": false,
         "allowGatewayTransit": false,
         "useRemoteGateways": false,
             "remoteVirtualNetwork": {
             "id": "/subscriptions/<subscription ID>/resourceGroups/PeeringTest/providers/Microsoft.Network/virtualNetworks/myVnetB"
             }
         }
         }
     ]
}

But then I modified the name to be, for example, vneta-tovnetb and it gave the me error.

If I use the vneta/vnetb as the name it does validate.

Answer 5

I hit the same issue and neither of the other answers worked for me, turns out there's actually slightly more to this than the other answers show. Firstly, for a root level resource, the docs specify it must:

...have one less segment in the name than in the resource type

In other words if you're creating a:

"type": "Microsoft.Web/sites"

Then as the name must have one less segment than the type, we can only use a single segment for the name in this example, i.e. one:

"name": "MySite"

For a nested resource the rule is:

the type and name have the same number of segments

However this assumes that you are shortening a nested resource's type e.g. creating a type of "Microsoft.Web/sites/config" as a nested resource within a parent of type "Microsoft.Web/sites" and for the nested resource specifying:

"type": "config"

So here you can also only specify a single segment name, e.g.:

"name": "MyConfig"

So putting that all together you have:

{
  "type": "Microsoft.Web/sites",
  "name": "MySite",
  "various other properties": ...,
  "resources": [
    {
      "type": "config",
      "name": "MyConfig"
      "various other properties": ...
    }
  ]
}

If on the other hand you specify the full type name in the nested resource (as shown in the accepted answer) you need to resort to the root naming convention of having one less segment in the name than the type! Converting the above you'd have:

{
  "type": "Microsoft.Web/sites",
  "name": "MySite",
  "various other properties": ...,
  "resources": [
    {
      "type": "Microsoft.Web/sites/config",
      "name": "MySite/MyConfig"
      "various other properties": ...
    }
  ]
}